The sad usability state of file permission setting functions in Windows and OS X

January 31, 2008

File permission setting in Windows and OS X could use a lot of improvements. As it stands, it’s very often unusable and people make many mistakes with it, thinking that they have configured permissions to one setting, whereas in reality the effective settings may be something else.

Today in Usable Privacy and Security class, Rob Reeder presented his research about this. I have always been wondering about that dialog, but I don’t think that I ever figured it out. And finally I think I’m somewhat getting it, after he as a PhD student explained it to me and the rest of the class :)

Just to make things clear, here’s the dialog I’m talking about.

You can already see that there are things here that make it difficult to use this dialog correctly. For example, the permissions have fancy names like “Full Control”, “Special Permissions”. Other examples that could appear here are “Modify” and “Write” (is there a difference? yes there is). Turns out that there are actually 13 “atomic” permissions that are true permissions in the traditional security sense of the word (in that they allow or deny some specific access), and then there are these meta-permissions that arbitrarily group some of the atomic permissions together, and these meta-permissions can be nested (one is subset of other), and so it is nearly impossible to understand what are the actual permissions applying to the file.

Somewhat amusing is also the fact that for any given permission and user, you can set both “allow” and “deny” at the same time. Conceptually this doesn’t make sense. Fortunately, at least for this particular situation, Windows is going with the more secure way and “deny” always takes precedence.

Now, add to the mix that this dialog only deals with permissions for this particular file. It does not consider that there may be inherited permissions from upper-level objects (directories), so it is impossible to see what are the permissions actually applying to the file. (There actually is a way to see this, but it’s several clicks away.)

There’s much more, but I won’t rewrite Rob’s and his co-authors article here, go read it yourself. In short, they do a user study to show that people make mistakes with this interface, and then propose an alternative interface where the error rate is lower. That one is not ideal either (he actually showed an even newer one they’re working on in class), but it’s better than what’s currently in XP.

I asked my classmates if anything has been improved in Vista, but apparently everything is the same.

Is Windows the only culprit? Is everything happy fine on OS X? Turns out OS X is somewhat better, but may still have people misinterpret its output or make mistakes. Here is the permissions setting part of the Finder UI.

Now… the good part about this one is that the permission names make much more sense. The possible values are “Read & Write”, “Read Only”, “No access”. There are also some other options like “Write only (drop box)” for folders and such. (Somehow, though, I can configure “No access” to “Everyone” but not “staff”).

What is that “staff” anyway? Doesn’t show up anywhere else in the UI. Turns out it’s the Unix file group. Unix traditionally has file permissions on three levels: user, group, everyone. There’s a many-to-many relation between users and groups, so users may be in many groups. Apparently “staff” is the default group. But for people not familiar with how that stuff works on Unix, this may be confusing.

Another big source of misunderstanding is that again, this dialog knows nothing about inherited permissions. I’m not even sure if there is an easy way to even see the composite inherited permissions for a file in Mac OS X either on the command line or UI. Most utilities seem to only work with permissions directly for that object.

A perfectly feasible explanation for this state of things on OS X is that most people never look at the permissions bits anyway, since the defaults are reasonable. For example the user’s home folders appear to be world-readable, but Desktop, Document, Music and other private default folders in it are not world-readable. So most people will not even need to worry about these settings. And for more complicated setups like networks, there may be some admin utility that takes care of it all and has a more usable UI to twiddle all these permission bits. I’m not familiar with Mac network admin utilities, so I don’t know which way it is.

I found a technical explanation of the OS X permissions system here. I remembered from the “old days” that on Linux, there was a special utility to work with ACL-s beyond the traditional user-group-world system, but turns out it’s part of the standard “ls” and “chmod” utilities on OS X:

The chmod(1) tool with the -a, +a, and =a flags may be used to manipulate ACLs. The “ls” tool with the -e flag may be used to view ACLs.

So to conclude with “further work” section :) it would be an interesting research idea to do some sort of comparative study between Mac OS X and Windows permission setting tasks and see if either of them is necessarily better or worse. Hm, I actually need to do a lab user study for that same usable security class, so maybe that’s one idea.

Let me know in comments if you have had good or bad experiences with permissions setting on either system.