MacEdition Logo

X-treme gotchas

By Tom Ierna (tomi@macedition.com), April 16, 2001

We’re a couple of weeks out from the official release of Mac OS X. Between Apple and third-parties, “weaknesses” in the 1.0 (or 10.0) release are being slowly resolved. Making up for some of the pain of the “not-quite-there” OS is Apple’s surprise release of the Developer Tools with every copy of Mac OS X. It’s a smart move sure to get more people to investigate the Cocoa environment.

This good news isn’t enough to counter some of the more serious issues that crop up though, such as an installer bug made up of three rather important components: problems with symbolic links, problems with permissions, and problems with incorrect or inappropriate files being deleted. Pax, a Unix-based archive utility, and Installer.app’s literal execution of directory deletion based on receipts appear to be the causes of these ills.

The symbolic link problem

Imagine you have two hard disks in your machine. You want one to contain only system software, and the other only to contain user applications, configurations and documents. To pull off this simple feat, you’d create a /Users/username/Library, a /Users/username/Documents, and a /Users/username/Applications for each of your users on the second disk. You’d then copy all of the files from those folders on the first disk to the same place in the hierarchy of the second disk. The final steps are to delete the original directories and make symbolic links to the new ones. In the classic Mac OS, this happens all the time. The Control Panels in the classic Apple menu is an alias to the Control Panels folder in the System Folder, for example. Mac OS X is no different in this regard. However, the pax-using Installer.app isn’t smart enough to realize when there is a link and when there is a folder. If an installer package has to install files into a directory that you’ve made into an alias, it will delete the alias and create a new directory of the same name, placing the files there.

That pax overwrites aliases with directories would only be an inconvenience if it happened to your Documents directory because your documents would still be on the second disk and the new stuff would be in the same place of the hierarchy of the first disk. You’d simply copy those new files, delete the old directory and make your alias anew. However, it gets dangerous when the aliases are down in the Unix guts of Mac OS X. Unix geeks everywhere can easily see where this would lead if you happened to make your /etc directory a link to another disk, and an installer overwrote the alias with a directory containing only the files it was installing. Old-school Mac buffs can imagine the analog of an installer replacing their System Folder with an empty one. Essentially, this would mean that next time you tried to boot the machine, it wouldn’t.

This first issue shouldn’t affect most users too much since only a few folks will be enabling root, and of those few, only a few will be making aliases of boot-critical resources. Of that fraction, some may run an installer which replaces their symbolic links with real directories, preventing system access to necessary files.

Multi-user permissions in a single-user world

Permissions are not an idea that’s familiar to most Mac users, unless they are cross-platform-savvy or if they have run an AppleShare server. However, permissions are common on multi-user systems – they’re used to limit file and directory access. Unix maintains three sets of permissions: one for owner, one for group and one for guest. Each set of permissions has three modes: read, write and execute. If I wanted my Documents folder to be accessible to me and only me, I would make sure my user owned the folder, and I would shut off read, write and execute access to group and guest. The Unix commands to do this are:

%chown -R tomi Documents
%chmod -R 700 Documents

The first command changes the ownership Recursively to tomi on the Documents folder. The second changes the permissions mode to 7 for owner (all access), and 0 (no access) for group and guest.

The problem with Installer.app is that it doesn’t respect the permissions which are currently in place – files in the package inherit the permissions of the user who runs them. Security holes could be opened if the Installer was run by the root user and if the package contained “setuid” executables, programs which inherit the abilities of the user who owns them, despite who runs them. This lack of respect can also be problematic when a package changes permissions to directories, creating situations where they become unreadable by certain users – or worse, by the OS itself.

Deleting file, BAD!

Apparently, Installer.app is rather literal. If a package is installed which places files in a specific directory and a subsequent package is installed over it which does not use that same directory, that directory is deleted. An improperly written package could wreak serious havoc on a system if this behavior is not expected. I can only surmise that this isn’t the behavior of installer makers in the classic Mac OS since Tenon Intersystems was able to create an installer which deleted critical system files, causing Mac OS X machines to become unbootable. To me, this behavior seems expected. In the classic Mac OS, installer makers won’t let you delete the System Folder, but some will let you move the System Folder to the Trash. This is helpful if you’re doing net installs of system software, but you have to be extremely careful since one wrong move could make a Mac flash the question mark. I don’t know if I’d call this one a bug, but this behavior should certainly be documented to hell and back.

Lucky for us, reinstalling is fast

The fact that anyone can now make an installer which can ruin a Mac OS X installation is definitely food for thought. The symbolic link and permissions issues can be solved by Apple if they’d use gnutar, a widely-used open-source archive utility, instead of pax. The third issue, incorrect or inappropriate files being deleted, could be solved by a thorough understanding of the behavior of the Installer tool – and documenting that behavior is definitely Apple’s job. However, the only issue which can bite you if you are a casual user of Mac OS X is the third one. The first two are irrelevant to most Mac users because they won’t be enabling the root account, changing the permissions on critical system files or moving system resources to other disks and joining things back together with symbolic links. As with any software, be careful – know the source, have backups, and for the first few months here, be prepared to reinstall the OS if a rogue installer package decides to overwrite your system files!

E-mail this story to a friend