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!