Applying Advanced Resource Control Using ACLs
New with Tiger, Apple has added Access Control Lists (ACLs) to the choices a user or administrator has in defining who can do what with a file. ACLs provide significantly more power than traditional Unix permissions. Where a traditional permission set can only detail what's allowable for the owner, the group, or “everyone else” for a particular file, an ACL can be so detailed as to individually define the permissions that are available for each user on the system. The types of permissions that are available are likewise considerably more fine-grained than the read/write/execute permissions controlled by the traditional Unix permissions system.
Understanding ACLs
Despite the considerable additional flexibility that ACLs provide, they are surprisingly simple to manipulate and understand. The primary commands for working with them are the chmod command, and the ls command with the -e flag. The former sets ACL entries, and the -e flag to ls cause it to list ACL entries for files it shows. The syntax is also simple:
chmod <modtype> "<who> <allow|deny> <what action>" <file or directory>
<who> is either a group or user specifier—that is, either a group or username. You can affect the permissions available to all users in the group staff, simply by specifying staff as the <who> parameter. Likewise, you can more specifically target the permission of the user miwa, by specifying only miwa if you choose.
<allow|deny> simply indicates whether the specified action is permissible or not for the specified user, for that file.
<what action> is a permission type that provides fine-grained control over the actions that can be taken with the file or directory. The applicable permissions for files and directories are documented in tables later in this section.
Finally <modtype> is a control flag for chmod that indicates whether the specified ACL permissions are to be added or deleted from the file's ACL.
Controlling ACLs in Tiger
ACLs provide overrides for the basic permissions supplied by the Unix permissions system. They therefore can be used to allow a select group of users greater access to a file that is relatively restricted by the basic permissions, or to restrict access for specific users on files that are otherwise relatively unrestricted.
The permission types that can be set are as shown in Table 11.5.
| These permissions can be set (allowed or denied) for files or directories | |
| delete | Allows (or denies) the named user or members of the named group to delete the file or directory. |
| readattr | Allows (or denies) the named user or members of the named group to read the objects basic attributes. |
| writeattr | Whether the basic attributes may be written. |
| readexattr | Whether the extended attributes may be read. |
| writeexattr | Whether the extended attributes may be written. |
| readsecurity | Whether the security policy (ACL) for the file may be read. |
| writesecurity | Whether the security policy (ACL, ownership, and mode) for the file may be written. |
| chown | Whether the named user or group can change the object's ownership. |
| These permissions can be set (allowed or denied) only for files | |
| read | Whether the file can be opened for reading. |
| write | Whether the file can be opened for writing. |
| append | Whether the file can be opened for writing, but only to add data, not to allowing overwrites of any existing (previously written) sections. |
| execute | Whether the file can be executed as a script or program. |
| These permissions can be set (allowed or denied) only for directories | |
| list | Whether listings of the contents are allowed. |
| search | Whether files may be searched for by name in the directory. |
| add_file | Whether new files may be created in the directory. |
| add_subdirectory | Whether new subdirectories may be created in the directory. |
| delete_child | Whether a contained file or directory may be deleted. |
ACL <modtype>s specify whether the following argument is to be added to or deleted from an existing ACL. The primary <modtype>s are +a and -a, which not surprisingly, add and delete ACL entries. There is also a +ai mode to cause inheritance of a property from the ACL of an enclosing directory, and +a#, -a#, and =a# modes to add entries in to specific locations in the list, delete entries from specific locations, or absolutely set specific entries in an ACL, respectively.
To actually use the ACL functionality, simply choose a permission, whether you wants to allow it or deny it to a particular user or group, and the files to which it should be applied. For example, if you have a file (myspecialfile) that you really want to let your friend (and co-user of the system) james edit, but you don't want to make it world-writeable, and you don't want to create a special group containing both you and james, you can use an ACL:
chmod +a "james allow write" myspecialfile ls -le myspecialfile -rw-r--r-- 1 joray joray 8567 Apr 25 17:27 myspecialfile owner: joray 1: james allow write
Now james has permission to write to your file. Depending on your standard Unix permissions setup, he still might not have permission to read it though! You can fix this by adding another ACL rule, or by chmoding o+r to the file—it all depends on whether you're worried about anyone else seeing the contents.
Perhaps you have a directory of files that you want to share with a bunch of other normal users, but you'd rather not have the admin users snooping around in your files. This, too, can easily be accomplished with ACLs (although if the admin users are stubborn enough, there's hardly anything you can truly prevent them from doing):
chmod +a "admin deny list" myhiddendirectory ls -lde myhiddendirectory/ drwxr-xr-x 2 joray joray 68 Apr 25 17:40 myhiddendirectory/ owner: joray 1: admin deny list
Now anyone in group admin is denied listing permissions for the directory myhiddendirectory. To increase the security, you might want to turn off admin's ability to change the directory security options as well:
chmod +a "admin deny writesecurity" myhiddendirectory chmod +a "admin deny chown" myhiddendirectory ls -lde myhiddendirectory/ drwxr-xr-x 2 joray joray 68 Apr 25 17:40 myhiddendirectory/ owner: joray 1: admin deny chown 2: admin deny writesecurity 3: admin deny list
If it turns out that james no-longer needs to edit your file, or you no longer want him to have access, the -a mode can be used to remove the permissions you've already created:
chmod -a "james allow write" myspecialfile ls -le myspecialfile -rw-r--r-- 1 joray joray 8947 Apr 25 18:27 myspecialfile
Now you're back to the normal Unix permissions controlling the access to the file.
CAUTION
Unfortunately…
As I write this in early April, ACLs still do not seem to work properly. Worse, despite repeated queries to Apple regarding where the GUI controls for these are located, we've seen no sign of an interface to ACLs in the Finder. In this section, we've documented how they're supposed to work, to the best of our ability, but some aspects of this information might be superceded by new developments as Tiger updates are released.