Lucid Nonsense


Permissions

Wednesday, 12 August 2009

Always repair permissions before an OS update. Any expert on OS X will tell you that this is imperative. Just like any high priest of Gorto will tell you to offer a sacrifice to appease Gorto before attempting any endeavor. And both will speak with equal conviction and basis in fact.
-CrazyAppleRumors.com

Operating systems are, in general, pretty complicated, and Mac OS X is no exception. Most of the time things run smoothly, but every now and then a problem crops up. One thing that has the potential of causing problems with Mac OS X is related to both the security system and the filesystem; file permissions.

File permissions aren’t fundamentally very complicated, they allow certain users to take certain actions with specific files and directories, while blocking other users or other actions. Prior to version 10.3 (Tiger), Mac OS X only supported the traditional POSIX style permissions, which in general1 are a case of three actions that can be set on files; read, write and execute (when execute is applied to directories it allows a user to open that directory). These actions can be set differently for the owner (normally the creator of a file), group, and others, which is “everyone else”. POSIX permissions are easy to understand and easy to implement. For example you can give the owner permissions to do everything to a file, a group the ability to only read a file but not write, and everyone else no ability to either read nor write to the file.

POSIX permissions are still available in OS X, but they are somewhat limited. For instance you cannot set different permissions for two different users on one file, you are limited to setting permissions for the owner, one group, and everyone else. There are alternative models that are used for file permissions, and Apple added one of these, known as Access Control Lists (ACLs), to Mac OS X 10.42. ACLs are more flexible than POSIX permissions and you are able to set much more finely grained actions. Furthermore these can be set for multiple users and groups at the same time. Other than the increased granularity and flexibility they achieve the same goal of either allowing users do certain things with certain files, or stopping them.

In addition to restricting the actions of a “real user” (ie a person) applications also use these permissions. They may have their own user (the web server in OS X has a user named _www for instance) or they may use the user id of the user who started the application (my Safari is using the user james at the moment for instance). What this means is that if an application, or even the operating system, doesn’t have access to a file it needs because the permissions are set wrong, then the application or system process can stop working properly or even crash.

In a perfect world this should never be an issue, but sometimes a badly configured installer, misbehaving application, user error, or disk error can cause a file required by a particular application or system component to have the wrong permissions set. This then breaks things.

Mac OS X includes a facility to repair certain permissions, which it does by checking information stored in /Library/Receipts that is supplied with applications and system components.. This repair doesn’t cover everything on your Mac and permissions are only repaired on files belonging to Apple software that was installed using the Installer application (rather than drag and drop). Apple have a short technote about the subject.

In general permissions rarely go wrong and repairing permissions is only required if there is a particular problem that can realistically be caused by a permissions issue. It is absolutely unnecessary to repair permissions as part of any routine maintenance procedure and, as my quote from CrazyAppleRumors.com above suggests, it is not something that needs to be done before system updates and other installations. If it needed to be, Apple would simply have the Installer application automatically run the process.

It’s not too hard to get an idea if a problem could be caused by a permissions problem, and this can save a bit of time when troubleshooting. Permissions either allow a particular type of access, or they do not allow it. There are no file permissions options that:

  • Allow access… but very slowly.
  • Only allow access once every 30 minutes, or on a Tuesday.
  • Cause Photoshop to crash when you check your Mail.
  • Slow your internet connection.

The kind of situations where file permissions could be at fault are generally more along the lines of:

  • Only some users can open applications.
  • Consistent errors with a particular application, or applications, especially when using a system level function (eg. printing)
  • Problems performing specific system tasks, such as system preferences not “sticking”.
  • Issues with Spotlight not indexing all of your files (because it doesn’t have the permission to read them for instance).

In addition remember that repairing permissions only affects a small subset of permissions on your system. Anything not supplied by Apple as part of the default OS X install, or an Apple application installed by the Installer app, won’t have any of its files touched by the permissions repair process.

Repairing disk permissions doesn’t cause any particular problems, but it’s a vastly overused tool whenever any problem appears with OS X, and is starting to take on the mantle of a Mac OS X version of “Have you tried turning it off and on again?”.


1. There are special permissions settings such as the sticky bit, but these are rarely used.
2. Only the server version of Mac OS X 10.4 had a graphical interface to ACLs, it wasn’t until 10.5 that the client version switched to using ACLs by default and included a GUI to access and modify them.


Previous Entry: "Mac Consultants & Engineers"

Next Entry: "Snow Leopard"