What happens during permissions repair in OS X?

One of the commonly recommended maintenance routines in OS X for tackling system slowdowns and other performance problems or odd behavior is to run a "permissions fix" on the boot drive. This is done with Disk Utility, and because it will not hurt the system to perform it is often one of the first suggestions people offer for troubled systems.

Permissions in OS X are file and folder attributes that grant a specific user or group access rights to that file or folder. There are two types of permissions in OS X, the first being traditional UNIX permissions, which are crude options that just manage access on a full read or full write basis (allowing or denying each). There is also an "execute" permission that allows scripts and other code to be executed as a process. The second type of permission is Access Control Lists (ACLs), which is more modern and offers a broad spectrum of permission settings besides simply reading or writing, such as the capability to create and edit documents within a folder, but not create new folders.

Every file and folder in OS X contains traditional permissions and optional ACL entries associated with it, which by default are set to allow appropriate access by user accounts that ought to have access to that file. You can see this if you get information on any file or folder and expand the "Sharing & Permissions" section, where you will see three entries listed. The first is the owner (likely either your username or "system" (the root account), followed by an associated user group (likely "admin" for administrators, or "staff" for standard human users), and then an "everyone" group for all other access.

This setup allows processes run under administrative accounts to perform tasks that the processes under standard user accounts cannot perform, including modifying system settings and denying access to private files within other users' accounts.

Not only are permissions useful for managing what users can access, they also can allow and deny background tasks access to files. For instance, if you set up Web sharing on your computer, then Web pages you make in your "Sites" folder can be read by the "apache" Web server background process on your system, which will then present the page to people who request it using a Web browser. If you set the permissions on a page to deny access to all users, then the apache process will not be able to read the page and will give an error like "404 not found" when someone tries to load that page.

In essence the permissions setup is like a key card security system for an office building, where each resource has an access point and any processes controlled by each user or group is granted or denied permission past that access point.

Some people may wonder why such restrictions are necessary, especially if only one user is using the system, and indeed some people have changed permissions settings system-wide to grant all users access without seeing any negative repercussions when operating the system. While granting full access at all access points will not immediately or necessarily hurt anything on the system, it breaks down the security structure of the system since it allows any running processes to access and edit any file.

Such a setup will not only allow the active user to access any file, but will allow any process running on the system to access all files and alter them. Because of this, if any action by you or a background process inadvertently attempts to delete or alter an important system resource, this action will not be denied and may result in a broken OS installation.

The permissions structure in OS X is defined by Apple's software engineers to provide only necessary access to system resources. For the most part files and folders can be read by any user or program, but not written to unless they have specific access (ie, administrators can install programs to the Applications folder, but managed users cannot). In defining these access conditions, Apple's engineers must assign all components of the permissions setup -- that is, the permissions for the owner, the group, and everyone else, along with optional ACL entries for the file.

In many cases only some aspects of these permissions are necessary for proper access to the file, and others are not. For instance, if you have a system setting file that is a member of the "admin" with read and write permissions for this group, then this means that it likely does not matter who the specific owner of the file is, especially if the owner is already a member of the "admin" group. Therefore, if the file's ownership changes from the default "system" to that of an admin user because the admin user modified or replaced it at some point, then proper and intended access to the file will still be set up. However, the file will not have the same permissions setup as was originally set by Apple's engineers. In this case, when a permissions fix is run on the system and the computer checks the permissions setup for this file, it will state that the ownership is different than expected.

The permissions fixing routine in OS X is a feature of the system that will check the permissions setup against a permissions database that is maintained on the system. This database is stored in the following two locations on the system:

/var/db/receipts (a hidden folder)
/Library/Receipts

Within these two folders you will find files that look like installation packages or the ".bom" (bill of materials) files and an associated property list (.plist) that are within these packages. These .bom files contain the locations of the installed files on the system along with their default attributes including permissions. The associated plist files contain any additional attributes including file versions, installation dates, and any ACLs.

When OS X is installed or updated, the installation process will deposit a receipt of its install package into these folders, and then when you install some programs, they too might place a receipt into these folders.

When you run a permissions fix using Disk Utility, the permissions check routine will read through all of the receipt packages and files in these two folders to get a location of which files to check and the attributes to check for. During this time you should see a process called "repair_packages" or perhaps Disk Utility show decent CPU usage in the Activity Monitor utility. The routine then compares the files on disk to those in this database and if a mismatch is found, even if the mismatch is a benign alteration such as that mentioned above, it will then output an error regarding this discrepancy and will revert the change.

Because standard use of the system will often result in small, benign alterations of the permissions settings on files, it is not uncommon for a permissions fixing routine to repeatedly list a number of permissions discrepancies. Therefore, do not be alarmed if you see such repetitions. The only time that altered permissions matter is if they either prevent access or allow too much access to files, in which case the permissions fix routine should clear the issue.

Another aspect of the permissions fix routine to keep in mind is that it will only work on files for which there is a receipt in the permissions database. This means that it will not touch files in your home folder such as your music or photo libraries, your Word documents, or even Internet plug-ins and preference files. It will also not touch any files you store on external disks and network storage solutions like Apple's Time Capsule or AirPort Extreme Base Stations.

Questions? Comments? Have a fix? Post them below or email us!
Be sure to check us out on Twitter and the CNET Mac forums.