Permissions Part 2: Using the Mac OS X Graphical Interface
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.