Access Control Lists in Tiger and Tiger Server
True Permission Management
08 August 2005 Matt Willmore Skip to comments
1 Comment
(
Closed)
__Access Control Lists__ (ACLs) are an improved way of managing access to objects and directories in a file system. Instead of the traditional UNIX-style approach of read/write/execute, ACL's give administrators an unprecedented amount of control over how file and directory permissions are managed. ACLs have been existent in server Operating Systems such as Windows and OpenVMS for some time; this is one area where Apple is playing catch up. Luckily, Apple has done a thorough job of adding ACL support without any headaches on the part of the user. ## Why Should I Care? ## ### True File Access Management ### ACLs bring about fine-grained permissions for objects and directories, something that OS X has been sorely lacking up to now. Without ACLs, server administrators are limited to the standard UNIX permissions: one owner, one user and allowance/denial to read, write and execute objects and directories. While these permissions are often adequate for a single user, they rarely fit the needs of an organization. ACLs allow admins to more accurately recreate the structure of an organization when defining permissions. ### Stored in Metadata ### Coinciding with the release of support for extensible metadata in Tiger, ACEs (access control entries) are stored in that very fashion. Unfortunately, Apple has chosen to not allow tools like xattr, which can view and edit that metadata, to see ACE entries. According to John Siracusa's review of Tiger, they're most likely prefixed with the reserved system namespace and therefore not editable withAre Access Control Lists the Next Big Thing for Apple's new Tiger Server? Matt Willmore explains ACL's and how they can benefit OS X Server admins and regular users alike.
xattr.
## Using ACL's with Tiger ##
Unlike some file systems that require you to reformat the drive to support ACLs, with Tiger you can turn ACL support on or off with a simple command. Besides the obvious ease of use, one immediate benefit is that if you ever get yourself stuck — say, a file that cannot be deleted by root, which you can certainly do — you can just turn ACLs off, and Tiger will go back to observing the standard UNIX permissions. The only requirement that Apple makes — besides Tiger, of course — is that the volume be formatted as HFS+. Since ACEs are stored in extended attributes (see "Stored in Metadata" above) Apple needs an HFS+-formatted drive to store the entries.
To enable ACLs on the client (non-server) version of Tiger, you'll have to use fsaclctl. To enable ACL support on the boot volume, for example, you would use fsaclctl as follows:
sudo fsaclctl -p / -e
Because the command affects a system-level property of the file system sudo will be required. The -p flag states the path of the mount point (in this case, /) and the -e flag tells fsaclctl to enable support. Additionally, you can mirror the command on _all_ HFS+ volumes at once by adding the -a flag. To disable support for a volume, substitue -d for -e.
In Tiger Server, you have the added benefit of a GUI front for enabling or disabling ACL support on each volume.
Apple has also added an API for integrating ACLs into programming for OS X. Details are available on the acl manpage. Also, note that API calls ending in \_np indicate that the routine is non-portable; that is, it differs from the standard POSIX.1e library for ACL's. _(Apple's implementation of ACL is based on the POSIX 1003.1e draft and is extensible for future improvements and additions.)_
### Before You Go Nuts... ###
Once you have ACL support enabled for a particular volume, we'll use chmod to change ACL entries on Tiger. Don't immediately go nuts and start changing everything you can find; rather, let's first look at what attributes can be set with a particular ACE. The manpage for chmod lists 17 distinct attributes, separated into sections:
__File System Objects__
* _delete_: Delete the item. Deletion may be granted by either this permission on an object or the delete_child right on the containing directory.
* _readattr_: Read an objects basic attributes. This is implicitly granted if the object can be looked up and not explicitly denied.
* _writeattr_: Write an object's basic attributes.
* _readextattr_: Read extended attributes.
* _writeextattr_: Write extended attributes.
* _readsecurity_: Read an object's extended security information (ACL).
* _writesecurity_: Write an object's security information (ownership, mode, ACL).
* _chown_: Change an object's ownership.
__Directories__
* _list_: List entries.
* _search_: Look up files by name.
* _add\_file_: Add a file.
* _add\_subdirectory_: Add a subdirectory.
* _delete\_child_: Delete a contained object.
__Files__
* _read_: Open for reading.
* _write_: Open for writing.
* _append_: Open for writing, but in a fashion that only allows writes into areas of the file not previously written.
* _execute_: Execute the file as a script or program.
__Interitance (Directories Only)__
* _file\_inherit_: Inherit to files.
* _directory\_inherit_: Inherit to directories.
* _limit\_inherit_: This flag is only relevant to entries inherited by subdirectories; it causes the directory_inherit flag to be cleared in the entry that is inherited, preventing further nested subdirectories from also inheriting the entry.
* _only\_inherit_: The entry is inherited by created items but not considered when processing the ACL.
## Let's Try This Out ##
To start working with ACLs, let's take a simple approach by working on files used just for practice. Create a new empty file with touch, and look at the permissions with ls -al. You can see that the user logged in is the owner, (in my case) the user is also the group and the permissions are set to 644 (owner [me] can read/write, group and everyone can both read). Without modifying the standard UNIX permissions, we'll change it so the group "admin" has access to write to and append the file but not read it. Accomplish the first part with this command:
chmod +a "admin allow write,append" file
Use ls -le (the -e flag instructs ls to print the ACL associated with each file that has one) to view the directory again, and you'll see that a plus "+" has been added to the listing for that file. Also, below the file the ACL is printed; in this case it will be "0: group:admin allow write,append".
Also note that ACLs do not have the ability to differentiate between a user and group with the same name. While this is common sense for most people, occasionally there will be an instance where a name is used by both. Avoiding this will avert a lot of problems.
Notice how we never modified the UNIX permissions? One thing to note here is that the ACL arguments are evaluated before the UNIX permissions; if there's no matching ACE, the system then evaluates the request based on the UNIX permission settings.
Now let's complete the other half: declaring that the admin group does not have the right to read the file. We can express that as so:
chmod +a "admin deny read" file
By using ls -le again, we can see that the new rule has been inserted. But why is it before our first rule? As it turns out, there's a specific order in which these arguments are evaluated. The correct canonical order is user-deny, user-allow, group-deny and group-allow. ACL entries can be entered at custom points using the +a# flag.
This is definitely something to keep in mind when designing your permission structure with ACLs. Now let's say we want to get rid of the entries we just created – not delete the file, but just remove the ACEs. We accomplish this with chmod again:
chmod -a "admin deny read" file
Sort of a pain to retype the exact argument, isn't it? We can speed things along by referencing the argument's number instead! If we look back to our example, we see that there's only the write/append allowance left. Instead of retyping the argument and using the -a flag, let's reference the number. We can do this by replacing the -a flag with -a#; the pound sign signifies that a number is being used instead of the string to reference the argument.
chmod -a# 0 file
Using ls -le will now not show any ACEs, but note that there is still an ACL attached to the file; it's simply empty right now. There are many other cool things that you can do with chmod; to learn more, man chmod is all you need (skip down to __ACL Manipulation Options__).
###Inheritance###
Inheritance is one of the trickier components of ACLs. By default, no inheritance is used when assigning an ACL. You can change that, however, by specifying an inheritence preference in the third part of an ACL entry with the standard permissions.
* __file\_inherit__ just says that files created in the directory will inherit the ACL entries of the parent directory.
* __directory\_inherit__ is the same as __file\_inherit__, but for directories.
* __limit\_inherit__ specifies that only the immediate subdirectories and files of the parent directory will inherit its ACL entries.
* __only\_inherit__ states that the directory containing the __only\_inherit__ ACL entry will not be affected by the entry, but subdirectories and files will.
However, it's also peritent to remember that the inheritance is "static", which means that permissions will only be applied the first time that the subdirectory or file is created; subsequent changes to the parent's ACL listings will not affect existing subdirectories and files (although new ones will certainly inherit the updated listings).
##Summary##
The introduction of Access Control Lists into OS X Tiger is very exciting to say the least. Once a subject of much want by administrators used to the flexibility and power of ACL's in other (arguably) industrial-strength server OS's like Windows 2003 Server, ACLs bring a strong, relevant tool to the OS X server toolbox and allow administrators to much more accurately match server permission structures to represent their company's organizational structure, and is scalable enough to do so well for small and enterprise companies alike. Although Apple has failed to give ACLs their due recognition, this is one tool that OS X Server admins should take a very long look at and consider integrating into their OS X Server setup.
##References##
* afp548.com — [Grokking Darwin ACLs](http://www.afp548.com/article.php?story=20050506085817850)
* afp548.com — [Tiger ACL's and everyone \[sic\] permissions](http://www.afp548.com/article.php?story=20050505114045482)
* arstechnica.com — [Mac OS X 10.4 Tiger: Page 8](http://arstechnica.com/reviews/os/macosx-10.4.ars/8)
* developer.apple.com — [Exploring Tiger Server](http://developer.apple.com/server/tigerserver.html)
* macintouch.com — [Mac OS X 10.4 Tiger Review: Security, Reliability and Compatibility](http://www.macintouch.com/tigerreview/tiger3.html)
* forums.macosxhints.com — [ACL's in Tiger Client](http://forums.macosxhints.com/showthread.php?t=38721)
* macosxhints.com — [Use Access Control Lists for fine-grained control](http://www.macosxhints.com/article.php?story=2005050120073947)
* eweek.com — [Is Mac OS X 'Tiger' Rolling Over on Windows Support?](http://www.eweek.com/article2/0,1759,1623307,00.asp)
* discussions.info.apple.com — [How do I enable Access Control Lists (ACL)](http://discussions.info.apple.com/webx?13@475.pcEganir47G.0@.68b13b44/0)
* docs.info.apple.com — [Inherit permissions does not work for AFP service](http://docs.info.apple.com/article.html?artnum=301601)
* discussions.info.apple.com — [XSAN and ACL's](http://discussions.info.apple.com/webx?13@475.pcEganir47G.3@.68af1fc2/0)
* wikipedia.org — [Access control list](http://en.wikipedia.org/wiki/Access_control_list)
Matt Willmore is a founding partner of MacZealots.com. Matt is also a Resident Assistant at Owen Hall and does Mac support at ECN, and is active in PUMUG. He can be reached at .
Reader Comments (1)
DISCLAIMER: The views expressed below are those of their authors and not necessarily endorsed or supported by MacZealots.com. In all cases, the comments provided here are offered as a courtesy and will be moderated. Any content deemed off-topic or offensive will be removed without notice. Posting a comment here boils down to two things: 1.) Think before you type 2.) Respect the thoughts of others. See our commenting guidelines and/or privacy policy for more information.
#1) On August 8, 2005 12:03 PM
The redundancy of the command (I’m guessing it is File System Access Control List ConTroL?) is astounding.