Volume Number: 20 (2004)
Issue Number: 7
Column Tag: Programming

Patch Panel

by John C. Welch

Access Control Lists

With all the hype that Tiger is getting for such "ooh..aah" features like multipoint iChat, Dashboard, etc, I thought today we should take a look at one new feature of Tiger that, while not as obvious as such GUI-goodness, will have a near - instant and far - reaching effect on all who use the new version of OS X: The implementation of Access Control Lists, aka, ACLs in Tiger.

ACLs are a new way of controlling, well, access to objects such as files and folders on a computer. Mac users currently don't have a traditional ACL implementation that ships with the OS. The closest thing we have now, is the login controls. That's a list of users who can log in to a Mac or Macs, and controls what they can do on a given Mac. So, in a sense, that's an ACL. It's a login ACL.

However, what most people use ACLs with are file system objects. Note: ACLs are by no means restricted to the file system. They can exist at any level where you have things you wish to control access to. But for this article, we're going to limit our discussion to the file system.

With current versions of Mac OS X and Mac OS X Server, you have traditional three-level Unix permissions. With any object on the file system, there are three levels of access:

• Owner, the user that owns the object

• Group, the group that has explicit access to the object. The Owner does not have to be in the Group

• Everyone else, or every user who's not the Owner, or in the Group, or every group who is not the Group.

There's a fourth access here: root. Root's the super user, it has full access to everything so there's no need to explicitly include root. The Owner is always a user; it can never be a group. (This is a step backwards in some ways from the older AppleShare permissions, which did allow for group ownership of a file.) The Group, (obviously) must always be a group, not a user. Everyone else is just that.

Within this access structure, there are three things you can do to an object:

• Read, that is, use the contents of the object in a non-modifying manner, i.e. viewing and printing

• Write, which lets you modify the object and/or its contents, so you can erase the contents of the object, delete the object, etc.

• Execute, which is what allows you to run a program, list the contents of a directory.

Everything you do with a File System (FS) object in Mac OS X is based on those nine bullets. It's fairly simple, although there are things that will catch you off guard. For example, if you own a file, but that file is in a directory that you don't have write access for, you can erase the contents of that file, but you can't delete the file itself.

Now, for a long time, this was all you needed. Access was simple, and could be simply controlled. But in a modern computing environment, these simple permissions fall down. For example, you can have a situation with different groups needing different access to a single directory and its files. The obvious solution is to put each group's files in a different directory, but then you could have some files needing to be seen by both groups. You can put people into different groups, but then you have to create another group with more restrictive permissions. In a large company, you can easily hit the Mac OS X limit of 16 groups per user in this kind of situation.

For example: You have an accounting group with its own directory on a server.

• The head of accounting needs unrestricted access to every object in that directory, and unrestricted control over the directory.

• The accounting managers need to be able to modify the contents of a directory, but not change permissions

• The IS group needs full control

• The accountants need to be able to modify files, add files, but not delete

• Non - accounting department heads need to be able to read and list specific files, but not modify them in any way

• Everyone else has no access at all to the directory

Now, you could make the head accountant the owner, he's set. IS can always use root (if all of them have that) or sudo to bypass permissions. You can set everyone to 000. So far we have rwx???---, because we haven't decided groups. Here's where Unix permissions fail. We have three groups now that we have to deal with:

• Accountants

• Accounting managers

• Department heads

We could make the group set for accounting managers, and now the directory is rwxrwx---, and put all three groups into a new group. Wait. We don't want department heads to have write/delete. Okay, put them into everyone. Wait, we don't want everyone to see inside the directory. The problem is, you have two groups that need rwx, and one that needs r-x. But within the first two groups, you don't want one to be able to delete files. Okay, set the sticky bit. but now, the group that DOES have to be able to delete can't, because the sticky bit means that only the head of accounting can delete files. So now he's doing the job of the accounting managers. Unix permissions are too simplistic to handle this, and this is not a terribly complex situation. If you are talking about a very large company, this scenario can get much worse.

However, a decent set of ACLs can make this really simple. For our example, since we don't know how Apple is implementing ACLs in Tiger, and even if we did, we couldn't talk about it, we'll use the ACL implementation from the OpenAFS project, (http://www.openafs.org/). AFS is the acronym for the Andrew File System, an open - source distributed file system that can run on Mac OS X along with almost every other modern OS. While AFS can easily emulate Unix file permissions, it has a much richer native set of permissions:

• r read the contents of files in the directory

• l list the names of files in the directory

• i insert files into the directory

• d delete files from the directory

• w write (or modify) files into the directory

• k lock (or modify the write-mode bit) of files in the directory

• a administer or change the acl of the directory

Note how the permissions, while more complex than standard Unix permissions, give you finer control. For example, adding a file to a directory is not the same as having write access to a directory. Deleting is its own permission, as is administering the ACLs of a directory. This is not the richest model of ACLs in use by any means. Both Novell and Windows have far richer ACL models, but this one is good as an example, and runs on many more environments than Novell or Windows do.

So let's revisit our accounting example, but with our new ACL goodness at our disposal:

• The head accountant is the owner still, and as such, he gets: rlidwka He can do anything, including modify the rights of others needing access. Cool.

• The IS group gets: rlidwka. Cool, they have the access they need.

• The accounting managers get: rlidwk. They can modify files as needed, but they can't change anyone's permissions in the directory. Cool.

• The accountants get: rliw. They can do their work, and add new files as needed, but they cannot delete files, lock files, or change permissions. Cool

• The department heads get: rl. They can see and view the files, but not modify them or the directory.

No one else has any rights; the directory is a black box to them. IS has the access it needs without needing sudo, or root access. If we had very strict security needs, (Sarb-Ox or HIPAA anyone?), we could set it up so that IS could manage ACLs for a directory full of files they could see, but not read. You could even set it up so they could run a directory they couldn't read at all. (Yes, obviously if they can manage ACLs, there's a fast bypass of ACL limitations, but the point is, you have more flexibility with ACLs.)

Another advantage that ACLs give us is individual user permissions outside of groups. So you can have multiple users with different access to a file system object. So you can easily assign new groups or new users permissions without having to modify the user and group organization of your network setup. You do have to be more careful with ACLs than Unix permissions, because if you aren't, it's really easy to give someone, or a group a lot more access than you thought you were.

We also don't know how various commands are going to be changed, or what new ones will be introduced to deal with the new permissions structures. But in the end, we're going to get a lot more benefit from ACLs than pain.

This is a bit of a quickie look at ACLs, but it should give you an idea of the kind of power that ACLs give you. Since ACLs are going to be implemented throughout Mac OS X, they should also finally give you the same permissions in the Finder as you have at the command line, unlike the current situation. With the way modern networking environments are becoming more complex, even k-12, Mac OS X needed a more flexible permissions structure, and ACLs are the best way to get there.

http://web.mit.edu/answers/unix/unix_chmod.html

http://www.apple.com/macosx/tiger/unix.html

John Welch <jwelch@provar.com> is an IT Staff Member for Kansas City Life Insurance, a Technical Strategist for Provar, (http://www.provar.com/) and the Chief Know-It-All for TackyShirt, (http://www.tackyshirt.com/. He has over fifteen years of experience at making Macs work with other computer systems. John specializes in figuring out ways in which to make the Mac do what nobody thinks it can, showing that the Mac is a superior administrative platform, and teaching others how to use it in interesting, if sometimes frightening ways. He also does things that don't involve computertry on occasion, or at least that's the rumor.