Permissions Part 2: Using the Mac OS X Graphical Interface
Date: Jun 10, 2005
Remember part 1 of this series? We looked at the Unix underpinnings of permissions and how to deal with them using the Terminal application. This time, we'll look at using the GUI tools of Mac OS X (version 10.3.9) to manipulate these file attributes.
The Finder is the program that provides a graphical interface to file and hardware (disk) permissions. To activate this feature, select the item in the Finder and then press Command-I. The result looks like Figure 1 for post-version 10.2 systems:
)
Figure 1 Finder information display for a file.
Because I am the owner of the file, I can change its permissions. Note that the folder is locked as far as the owner goes because the folder is located on my desktop. If it were located in another place, it may not show up as owner-locked. Any changes made through the get–info window will be immediately effective, even before the window is closed.
Notice the button called Apply To Enclosed Items. Apple will tell you that pressing it will make any changes you make to an attribute apply to any enclosed folders. Well, that's not exactly correct. Some changes will propagate, (such as permissions), but Owner and Group will not.
Apple acknowledges that this affects OS X versions 10.2 through 10.3.9 (see this site). Apple first noted this in August 2002, and it isn't yet fixed. Apple's workaround is to drop into Terminal and use the chown and chgrp utilities with the -R option.
Utilities
The primary utility for interacting with permissions is Disk Utility (DU), which is found in the Utilities folder.
DU has a button to see whether your permissions on a disk are out of whack. The following figure shows a typical output. Even if only verification was selected, DU will repair/change permissions on certain files without your explicit permission. Figure 2 shows this happening.
)
Figure 2 Disk utility checking permissions on a disk.
DU also creates a log that can be examined through the Console utility, in which all created logs are viewable. Figure 3 shows the log output of the same run as above.
)
Figure 3 Disk utility log output.
There is also a button in DU to allow Repair Permissions. This process has become a magic incantation of sorts among those who want to sound more geek than they really are, as in "I installed an upgrade and ran repair permissions, of course."
The problem with DU is that it does not really repair permissions; it restores them to their initial values. It finds these initial values from the install package receipts. Thus only software that has been installed from a package (like Apple's software) will be affected by running the repair option. Everything else will be ignored (because there is not way to compare the current settings to the original ones when the program has no idea what the original settings were), and the user will not be informed that only a partial repair has been done. So, just invoking DU after some third-party installer program (Adobe CS, for example) messes everything up will fix only those files that have been put on your machine through a package. Other files will need to be corrected manually, which may mean a complete "wipe and install" cycle, in which applications are reinstalled from original sources.
Why Permissions in the First Place?
At some point, one has to ask this: Why should we be messing with the permissions in the first place? What is it that causes them to be important?
Usually, a user wants to do this because the OS will not allow them to do some sort of manipulation on the file. Perhaps the trash can't be emptied because with OS X you lack permissions to do so. Or you want to move the file somewhere and the OS will not let you do so.
If you are the administration account on the machine (or the remote machine), these restrictions can be very frustrating. Permissions are supposed to stop users without authorization from messing things up. They shouldn't serve as an obstacle to the administrator.
The reason why an administrator is impeded requires a new look at OS X and the environment in which it functions. Unlike other Unix-derived systems, OS X has been designed for compatibility with legacy applications and files that were never designed for a rigid owner/permissions structure. That means OS 9—aka "Classic."
This dichotomy meant that OS X has to simultaneously live in two worlds at the same time; one with owner/permissions and one without. This lead to a design compromise in OS X that is not really talked about too much: variable ownership.
Who's Your Daddy?
There is an obvious trail to this concept hiding in the disk information that is displayed in the Finder. If you look at the Get Info dialog box for a Firewire disk plugged into your machine, you notice the following check box: Ignore Ownership On This Volume. That means that on that disk every user can access every file; that is, each user that looks at a file will "own" it.
Now, let's say you wanted to perform some file manipulation (such as copying it or backing it up) on a file you own that required becoming the root user to perform the action. root would then own that file while the manipulation occurred, and the new/copied file would think it was owned by root—who created it. After you go back to being the administrative user, you are no longer 'root'. But because of this promiscuous ownership, the new file may still think 'root' is its daddy and won't give it up for you even if you owned the original file.
The simplest solution to this problem is to invoke terminal, become root (say the magic password!) and play with the chown command until everything is as it should be.
And that, kids, is why you need simple Unix skills in OS X to this day.
Summary
I introduced a number of complex concepts in a short space and am painfully aware that they are not fully developed in this article. But the point of all of this remains simple: Even if OS X is graphically based, you sometimes need to punch out command-line instructions to get things done.