These Permissions Are Not The Repairs You’re Looking For – A Critical Look at Permissions in OS X

So, your Mac is acting up. Indeed, a Mac is no more impervious to Murphy’s Law than a non-Mac PC (I use PC here in the literal sense to signify personal computer). What do you do when the inevitable occurs? The first response for many to this will differ – some will seek out a solution, some will be adept enough to tackle the problem head on, some will likely do some sort of voodoo dance (if life has taught me anything, it’s that if you can imagine it, someone else also has and has probably tried it), some will ask for help online and others will simply stare down their machine hoping it acquiesces. Many however will fall back on the supposedly tried and tested fix all: repairing permissions. After all, it has two seemingly ameliorative words sitting right there, staring you in the now likely frustrated face. Who wouldn’t want to repair something, especially when it’s something called permissions? After all, don’t we continually seek out permission to do something?

In this article, I want to address the fallacy of permission repairs. In other words, I want to look at why repairing permissions really doesn’t solve as much as the title would imply.

The Fallacy of Permissions
Building on cradom’s recent set of fantastic articles on the command line, I want to expand on one particular notion that he discussed: permissions. For the sake of this article, I want to emphasize one simple point about them. Simply put, permissions are not an all or nothing thing. In other words, permissions don’t work like a binary in that they don’t wholly restrict or permit access to a file. Like many things in life, there’s very much a grey area in there. For the sake of demonstrating this, I’ve written a very short script designed to do nothing more than open a file, read the name in that file and then say ‘hello’ to that person. In so doing, I want to show that setting different permissions on the file with the name has different consequences but in so doing, I hope to highlight that a variety of permissions on that file can also lead to the same outcome.

For those interested, I’ve written the short script in Python. What follows is the script itself:

f = open("name.txt", "r")
print("Hello %s" % f.readline())
f.close()

All that script does is open a file called name.txt, read the first line (the only line and the one that contains the name), and print back to the screen “Hello” and the name from the file.

Experiment Time
Now that we’ve got our test case ready, let’s do some testing. By default, the permissions on name.txt are “-rw-r–r–” or, in octals, 644. For those who haven’t read cradom’s articles, the part to focus on is the rw at the beginning. For the current user (you), the default permissions on that file are read and write. In other words, you can do whatever you like with that file. Consequently, when I execute that script, it happily executes and does the following:

This is hardly surprising – the default permissions on a file that you created shouldn’t somehow restrict you from doing work. If the default permissions were not read/write for user generated files, using your Mac would be an exercise in frustration.

Let’s play around with the permissions on that file for a moment. Let’s remove the write permissions (set them to “-r–r–r–” or 444) such that the file can only be read but not written to. The consequences of this are quite simple – you can no longer edit the file. If you try, you’ll be greeted with a message similar to the following:

Looks like our file is messed up, right? Not quite. Our script for example is happy to continue doing what it did with the default permissions:

The reason for this is quite simple – our script was only looking to read the file and it had no interest in modifying it. That said, the nature of the file has changed and certain functionality in other apps (such as TextEdit’s ability to modify the file) is now lost. Here is our grey zone – the file has had its nature changed but it’s still very much accessible to applications that don’t care about the lost access. Think of it this way. Pretend (if you’re not already) that you’re bilingual and speak both English and Dutch. If someone enters the room and vacillates between both languages, you’d have no issue following the conversation. However, unilingual people in the room would be utterly confounded when the speaker switched to the unfamiliar language. A similar thing is happening here with the permissions. TextEdit loses functionality when you switch permissions but some applications couldn’t care less what “permission language” you’re speaking as long as the one they want is there (as with our hypothetical above, as long as English or Dutch is being spoken, all is well).

Enter the Fallacy
The example I provided above is an incredibly simplistic example of how permissions work along a gradient instead of an all or nothing binary. In showing what I did, I sought to illustrate that there are no right or wrong permissions that are universal, except for perhaps no permissions (“———-” or 000), which, as far as I know, screw up everything for any application that tries to access it. Here is where popular myths around permissions begins to creep in. Permissions, for many, fall into the binary template of right/wrong, neglecting the nuances of this form of access control. You can see from the example above however that changes in permissions have differing consequences, some detrimental and some that are irrelevant and/or non-existent. Changing the file to read only for example meant nothing to my script but it has dramatic consequences for TextEdit, which felt compelled to warn me that the file couldn’t be written to.

It is these consequences that highlight the ways in which a no access/full access understanding to permissions is a fallacy. Nothing stops some apps from working when slight permissions changes are made, a set of slight changes that could restrict/grant access to features elsewhere. This has bearing on the popular myth that repairing permissions can fix numerous non-specific or obvious problems. It is entirely possible for permissions to change on a file that have no adverse consequences for the misbehaving application. Assuming my script was something used on a regular basis, various changes to the permissions on name.txt would be of no issue. “Repairing” them back to the default, while restoring functionality elsewhere, would be of no help in solving any problems around my script if it was acting up.

Repairing Permissions – In-Depth
I’m going to start with a bold claim here and ease up on it throughout but I want to start by unsettling some misconceptions about its efficacy: repairing permissions to solve an application-based problem is as effective as putting your machine in the corner for a time out. Yes, I have just made the claim that repairing permissions is useless and although this is not entirely the case, I want to start with the futility that comes with trying to fix permissions at a system level to solve rather banal problems.

Let’s start with exploring what happens when you ask Disk Utility to repair the permissions on your computer. As Apple’s website notes:

Many things you install in Mac OS X are installed from package files (whose filename extension is “.pkg”). Each time something is installed from a package file, a “Bill of Materials” file (whose filename extension is “.bom”) is stored in the package’s receipt file, which is kept in  /Library/Receipts/ in Mac OS X v10.5 and earlier.

Why start with this quote? Simple – this statement outlines what is subject to the repair permissions feature. Indeed, as the site notes:

In Mac OS X v10.5 or earlier, when you verify or repair disk permissions Disk Utility reviews each of the .bom files in /Library/Receipts/ and compares its list to the actual permissions on each file listed. If the permissions differ, Disk Utility reports the difference (and corrects them if you use the Repair feature).

Translated into simpler language, Apple is essentially saying that when you install something from a package file (.pkg), a receipt is saved that lists the permissions of each file that are contained in the installer. When you ask repair permissions to fix issues, it goes through each of these receipts and compares the lists there with software on your machine. Note how this only checks the bom files (our receipts) for installed packages and excludes other files. Consequently, the list of excluded content can be quite long, a length that Apple alludes to:

Files that aren’t installed as part of an Apple-originated installer package are not listed in a receipt and therefore are not checked. For example, if you install an application using a non-Apple installer application, or by copying it from a disk image, network volume, or other disk instead of installing it via Installer, a receipt file isn’t created. This is expected. Some applications are designed to be installed in one of those ways. Also, certain files whose permissions can be changed during normal usage without affecting their function are intentionally not checked.

Non-Apple installers would include the ones for Adobe CS products for example, especially if you use Creative Cloud. Disk image installs are easy to list since most applications come this way (so I won’t list any) and applications/files that change permissions purposively, although a mystery to me, do broaden the umbrella under which non-affected files lie.

You might, at this point, still be thinking that it’s still an effective method of correcting system issues. Perhaps it might but we’re still largely at “in the corner for timeout” effectiveness here especially if this is used as a remedy for non-pkg installs and system functions. What then does it fix? Let’s take a look.

As noted above, /Library/Receipts is the key here. Let’s take a look at my machine as an example:

Well, that’s…underwhelming. As you can tell, my /Library/Receipts directory is, to put it mildly, sparsely populated. The db directory is empty, there is one plist and one pkg file. There are no bom files, suggesting that there are no bill of materials that will be checked when (or should I say if?) I check and repair permissions. Consequently, my machine, a rather average machine, will benefit in no way from repairing permissions (not quite but we’re not there yet in the discussion).

At this point, you may also be saying “well, what about the huge list of permission issues that Disk Utility reports back, none of which have anything to do with installed applications?” This is a very valid question and one that addresses what appears to be a flaw in Apple’s own documentation about Disk Utility’s focus on bom files. However, if you look at this document, you’ll notice that a good portion of them can be ignored.

This is the point at which I ease up on the “in the corner for a time out” comparison. I don’t want to suggest that repairing permissions is always going to be useless. As Apple notes:

Disk Utility repairs the permissions for files installed by the Mac OS X Installer, Software Update, or an Apple software installer. It doesn’t repair permissions for your documents, your home folder, or third-party applications.

Well, this would suggest that system level software can be fixed with a permission repair. After all, system level software is installed through these vehicles (or, I imagine, the Mac App Store). OS X installers, Apple installer installed software (the next, next, next wizards that are mostly standard) and software updates get included in the check, indicating some utility for permission repairs. But, note the limits of this – repairing permissions applies only to a small portion of the files on your computer, not user generated ones (such as my script and test file) or ones that fall outside of Apple’s criteria for checks (as listed earlier).

Conclusion
Repairing permissions has long been a go-to fix for a lot of problems that seem to linger or magically appear. It even sounds good. However, it’s a very limited tool and the scope of its potential very much limited through its design. Permission repairs don’t fix all issues and if something goes wrong that falls outside of Disk Utility’s scope, you’re better off yelling at your machine because that will likely take less time.

At the same time, it’s important to remember that permission errors, if they do appear, may not even be errors at all. Permissions are inherently nuanced and what appears to be an issue may not actually be an issue. If someone says that “I can’t read my document” and it has read only permissions set, permissions aren’t the issue (although, they’ll likely want write permissions set). At the same time, the smallest of tweaks can break an application without the changes having adverse consequences elsewhere. Thus, if something is wrong with accessing a file, permissions are a good place to start. The place to start from though isn’t always Disk Utility.