Access control lists
Access control lists, or ACLs, are a finer-grained, more flexible way to control file permissions: who can do what to which files. In Tiger, ACLs are a supplement to the traditional Unix file permissions. Since I've never covered Unix file permissions in a Mac OS X article before, I'd like to do so now. Feel free to skip this section if you already know this stuff.
In Unix, each file belongs to a single user and a single group. Unix file permissions control the ability to perform three actions: read from a file, write to a file, and execute a file. For a given file, the permissions allow or deny each of these three actions for the user who owns the file, the group the file belongs to, and everyone else. That's a total of nine permissions: read, write, and execute for owner, group, and other.
In the text-based interface of Unix, the actions are traditionally abbreviated by the letters "r", "w", and "x." The file's owner and group are also displayed. Here's an example:
The file above belongs to the user "john" and the group "staff." The first character of the permissions string indicates the file type. It is "-" for normal files (as shown above), "d" for directories, "l" for symbolic links, and so on. The example above grants read, write, and execute permissions to the file's owner (john), group (staff), and "everyone else." Here's a more restrictive example:
In this example, the owner (john) can read and write to the file, the group staff can only read it, and everyone else cannot read, write, or execute it. The "-" characters within the permissions indicate a lack of a particular right.
These permissions are typically implemented as a bit mask, with one bit for each letter in the permissions string. Each cluster of three permission bits can be represented by an octal number: 000 through 111 in binary, which is 0 through 7 in decimal. For example:
The file in the example above is said to be in "mode 640."
There are actually at least three more permission bits that precede the "owner" bits. These control permission inheritance for directories (often in a vendor-specific way) and the ability of the user executing the file to temporarily assume the identity of the file's owner or group. Thus, the full "mode" string is "0640" in the example above, assuming none of the "extra" three bits are set.
You can read more about the display and modification of file permissions by running "man ls" and "man chmod" from the command line.
Traditional Unix file permissions are flexible, but it's still not hard to construct scenarios in which they do not offer enough control. For example, imagine trying allow a single user, Bob, to read one of your files. With traditional Unix file permissions, the only way to do it is to make a new group (say, "friends") with just two people in it, you and Bob. Then you'd change the file's group to be your new two-member group, and enable the group read permission.
That was awkward, but now imagine that you want to let a third user, Ray, write to the file, but not read it. Now you're stuck. If you put Ray into the "friends" group, he'll be able to read the file. And if you grant write access to the "friends" group, then Bob can write to the file. Since a file can only have one owner and one group, there's nothing you can do. The Unix permission system is not flexible enough to accommodate these needs.
Worse, imagine that you want to grant the ability to delete a particular file to a group of users. In traditional Unix permissions, there is no "delete" permission for a single file. The ability to delete a file is controlled by the "write" permission of the parent directory. But you want to allow just this particular file to be deleted, not all files in the same directory. The Unix permission system is not fine-grained enough to accommodate these needs.
Enter access control lists. An ACL is an ordered list of rules that control file permissions. Each rule specifies three things: an actor, an action, and whether that action is allowed or denied. A rule is also known as an ACE, or access control entry.
To determine whether or not to allow an action, the rules are considered in order. The first rule that is applicable to the current actor and action determines the decision, and no further rules are considered. If none of the rules apply, then the decision is determined by the traditional Unix file permissions.
Note that the Unix permissions are not even considered unless none of the ACEs are applicable. It's possible to have a file that "appears" to be readable to everyone, for example, but that actually allows no one to read it, or just allows a single user to read it, and so on. In effect, the Unix file permissions can be totally ignored if the access control list contains rules that apply to all potential actions and actors.
(It's actually a bit more complex in the case where multiple actions are requested simultaneously—opening a file for reading and writing, for example. But the overriding rule is the same: ACEs take precedence over Unix permissions.)
ACLs can be modified from the command line using the chmod command (run "man chmod" for details) or the Workgroup Manager application in Mac OS X Server.
For ACLs to work at all, they must be enabled for a particular volume. The Workgroup Manager application in Mac OS X 10.4 Server can do this, but that application is not included with the normal (non-server) version of Tiger. There is a command-line work-around, however. This command will enable ACLs on the boot volume.
% sudo /usr/sbin/fsaclctl -p / -e
Here's a brief demonstration of ACLs. Let's start with a file named, appropriately, "file."
% touch file % ls -l file -rw------- 1 john admin 0 Mar 31 21:12 file
Right now, only the user "john" can read and write the file. Now let's revisit the earlier examples where Unix permissions fell short. With ACLs, they become trivial.
- Allow a single user, Bob, to read one of your files.
% chmod +a "bob allow read" file
- Let Ray write to the file, but not read it.
% chmod +a "ray allow write" file
- Allow a group of users (say, "staff") to delete the file.
% chmod +a "staff allow delete" file
You can use the new "-e" option to the "ls" command to show a file's ACL from the command line.
% ls -le file -rw------- 1 john admin 0 Mar 31 21:12 file 0: bob allow read 1: ray allow write 2: staff allow delete
Note again that the Unix file permissions have not changed. If Bob tries to read, Ray tries to write, or anyone in the "staff" group tries to delete the file, the Unix permissions will not be consulted at all.
The chmod command can add or remove ACEs and insert them in specific positions in the ACL. Remember, it is very significant that ACLs are ordered lists; the first rule that matches, "wins."
I mentioned the increased granularity of ACLs. This screenshot from the Workgroup Manager application in Tiger Server gives you an idea of what's possible.
Workgroup Manager ACL panel (Tiger Server only)
Remember, each ACE can allow or deny any of those actions to any user or group, and there can be an unlimited number of ACEs per file (conceptually, if not necessarily practically).
ACLs support "static inheritance." This means that the initial ACL for a newly created file may be determined by the ACLs of one or more of the parent directories. This inheritance happens once, at the time the new file is created. If the ACLs of the parents change in the future, the children won't inherit those changes.
The one-time nature of the inheritance is what makes it "static." As you might imagine, the opposite system, "dynamic inheritance," is very difficult to manage, with changes to a single directory potentially rippling through existing files and directories below it. Apple definitely made the right choice here. (As one reader pointed out, having support for both forms of inheritence might be even better. But I'd still choose "static" as the default mode.)
Tiger also does away with the 16-group limit from Panther and earlier versions of Mac OS X. Now a user can belong to any number of groups. More interestingly, groups can be nested, creating a hierarchy of groups. For example, the "staff" group could encompass all employees, while the "managers" group could be a subset of "staff," and "executives" could be a subset of "managers," and so on.
Setting an ACE like "staff allow read" will allow "staff," "managers," and "executives" all to read. Setting an ACE like "managers allow write" will allow "managers" and "executives" to write, but not members of "staff." You get the idea.
Needless to say, this is a huge windfall for anyone who has to administer a Mac OS X server. ACLs allow file permissions to more closely match the hierarchy of the organization.
ACLs have existed in various forms in many other operating systems over the years. In many ways, Tiger is playing catch-up here. Even classic Mac OS has some file sharing features that are beyond the capabilities of traditional Unix file permissions.
The addition of ACLs to Tiger was significantly motivated by the mismatch between Unix permissions and the Windows/Active Directory permissions model. With Tiger, Mac OS X can finally serve files to (and exist as a full peer on) a Windows network.
Before leaving this topic, I'd like readers to consider this: where, exactly, does Tiger store all of this new file permission information? Where is the "list of access controls" for each file?
Well, where are the Unix file permissions stored? They're in the file system metadata structures, of course, along with the file name, modification date, and so on. ACLs are stored in the same place. But rather than being forced to change the HFS+ volume format in an incompatible way in order to add this new metadata (requiring a complete reformat to use ACLs), the ACLs are stored in (you guessed it) extended attributes on HFS+ volumes.
(The ACL attributes are apparently masked out by the extended attribute APIs in Tiger, so you won't be able to see them with the xattr program. They also likely use the reserved "system." namespace prefix for their attribute names.)
This is just one fulfillment of the promise of that long-requested, esoteric-sounding feature, "arbitrarily extensible file system metadata." For people who couldn't see past the status quo, the ability to associate arbitrary pieces of data with any file or directory has long seemed interesting, perhaps, but largely pointless.
It appeared that Apple itself was in this camp at the dawn of the Mac OS X era. With Tiger, Apple has started to turn the ship around. Even the staunchest critic of the campaign for more, better file system metadata has to admit that it's pretty nice to get all the features of ACLs without having to reformat your disk.
In a (mercifully) rarely read rant on the future of Mac OS X, written on December 7th of 2001, I railed against opponents of greatly enhanced file system metadata, and warned of the inevitable future that Apple may not be a part of if it doesn't wake up.
Make no mistake, the future of computing will be absolutely lousy with that hateful, performance robbing, compatibility-impairing, complexity-increasing metadata—with or without Apple. To doubt this is to deny the entire history of computing—to think that this, somehow, will play out differently than every single other technology that has come before it.
Before moving on with the article, I just want to express my relief that the anti-metadata sentiments publicly expressed by many people, and apparently shared by Apple at the dawn of the Mac OS X era, have been wisely left behind.
Steve Jobs visited Xerox PARC in 1979. In an interview in 1995, before Jobs returned to Apple, he had this to say about his first glimpse of the graphical user interface at PARC in 1979.
Within ten minutes it was obvious to me that all computers would work like this some day.
Many employees at Apple were already onboard the GUI train prior to 1979, and Jobs visited PARC largely thanks to their urging. After the visit, he saw the proverbial light, and the rest is history.
I suspect that nothing quite so dramatic or significant has happened in the case of file system metadata, but I don't think it's too far-fetched to imagine a somewhat similar situation. It's not hard to guess which side Apple employees like Dominic Giampaolo come down on, but the wildcard has always been Jobs himself. Convince him of the merits of your ideas and you're home free.
Right now, I'm not actually sure that Jobs is fully on the file system metadata bandwagon. In fact, I'm not sure he cares about—or is even aware of—the issue at the implementation level. His job is to worry about the big picture; the smart people he hires are supposed to hash out the technical details.
Two things are made clear by Tiger. First, the consensus of Jobs's technical advisers has clearly tipped in favor of the pro-metadata camp. How long ago this happened or how far it has tipped is anyone's guess. Second, Jobs is convinced enough of the merits of this approach that he is, at the very least, not actively thwarting efforts to improve this area of Mac OS X.
This may sound like damning with faint praise, but I really am glad to finally see some external sign of a turn around on what I feel is a very important issue. Metadata is the future, and I'm glad to see that Apple's decided to come along for the ride.
But wait, there's more...