OS X ACL usage

Starting with 10.4, Mac OS X has ACL's. The "chown" man page tells you about their usage, but it leaves a little bit out and isn't all that helpful.

If you landed here searching for a basic introduction to OS X permissions, I recommend Brian Tanaka's Take Control of Permissions in Mac OS X, a $10 PDF E-book that will teach you the basics. The article you are reading here is a bit more advanced.

You need to turn on ACL's before you can use them. To enable the root filesystem, I'd do:

sudo fsaclctl -p / -e

The "-e" enables ACL use, "-d" disables. No reboot required, the change is instantaneous (the man page says you do need to reboot or remount).

ACL's are listed by adding "-e" to a long "ls" listing:

ls -le

You'll notice nothing different about the output unless you had acl's enabled previously. However, there is a little oddity there: if a file EVER had an ACL list, and the ACL's were later deleted (see blow), a "+" sign will appear in the "ls -le" listing:

$ ls -le
drwxr-xr-x + 2 apl apl 68 Jul 19 18:32 foo

Turning off with fsaclctl does not delete ACL's; it just makes them temporarily invisible and ineffective:

$ sudo fsaclctl -p / -d
$ ls -le
total 32
-rwxr-xr-x 1 apl apl 3740 Feb 28 07:34 dstate.pl
drwxr-xr-x 2 apl apl 68 Jul 19 18:32 foo
-rw-r--r-- 1 apl apl 900 Feb 28 07:34 s
-rw-r--r-- 1 apl apl 4662 Feb 28 07:34 time.dat
$ sudo fsaclctl -p / -e
$ ls -le
total 32
-rwxr-xr-x 1 apl apl 3740 Feb 28 07:34 dstate.pl
drwxr-xr-x + 2 apl apl 68 Jul 19 18:32 foo
-rw-r--r-- + 1 apl apl 900 Feb 28 07:34 s
  0: group:admin allow write
  1: user:tony inherited allow write
-rw-r--r-- 1 apl apl 4662 Feb 28 07:34 time.dat

In the above listing, "s" has two ACL's, and "foo" has none (but "foo" had one or more ACL's sometime in the past).

You apply ACL's using extended chmod commands:

$ chmod +a "tony allow delete" foo
$ ls -lde foo
drwxr-xr-x + 2 apl apl 68 Jul 19 18:32 foo
  0: user:tony allow delete

The format is always user or group, allow or deny, attribute. By default, rules stack as you apply them:

$ chmod +a "admin allow delete" foo
$ ls -lde foo
drwxr-xr-x + 2 apl apl 68 Jul 19 18:32 foo
  0: group:admin allow delete
  1: user:tony allow delete

Notice that the new rule became rule #0? You can control the positioning:

$ chmod +a# 1 "admin deny delete" foo
$ ls -lde foo
drwxr-xr-x + 2 apl apl 68 Jul 19 18:32 foo
  0: group:admin allow delete
  1: group:admin deny delete
  2: user:tony allow delete

Macworld Mac Security Superguide $9.99

That pushed are new rule in between 0 and 1, and also shows why we'd need or want to do that: which rule matters now? We say in 0 that an admin can delete the file, and in 1 that we deny that ability. Which takes precedence?

The "deny" takes precedence, but would even if we reversed the order. "Allow" rules are cumulative, so order is unimportant, but "Deny's" short circuit and take effect the moment they are encountered: no more rules are read.

Deleting ACL's is easy:

$ chmod -a# 2 foo
$ chmod -a# 1 foo
$ chmod -a# 0 foo

Because the rules would "move up" as they are deleted, you could accomplish the same thing with:

$ chmod -a# 0 foo
$ chmod -a# 0 foo
$ chmod -a# 0 foo

Inheritance ACL's can be added to directories:

$ chmod +a "admin allow delete,file_inherit,directory_inherit" foo

Any NEW files or directories we create in foo will inherit the ACL "admin allow delete". Directories in foo will also inherit the "inherit" attribute and will pass that on to their files and directories. We may not want that, so we can instead say :

$ chmod +a "admin allow delete,file_inherit,directory_inherit,limit_inherit" foo

That applies the "admin allow delete" to files and directories created in "foo", but doesn't keep passing that on down. There's one more inheritance that is useful:

$ chmod +a "admin allow delete,file_inherit,directory_inherit,limit_inherit,only_inherit" foo

The "only_inherit" avoids applying the ACL to "foo" itself.

Read the "chown" man page for the list of attributes that can be allowed or denied with ACL's.

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them.

I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Comments




Tue Apr 1 15:14:05 2008: Subject:   Mike


Ah! Thank you; I've been tearing my hair out as to why a collection of NFS mount points were mounting and showing correct disk usage info, but couldn't be seen by the users who were supposed to see it. I wasn't aware of having to enable ACLs on the client root FS, and now I am.

Thanks again.



Fri Apr 18 10:41:21 2008: Subject: ACls "@"   pmstar


Hello,

I am having trouble with ACLs...I had issues when I was no longer able to rename or move some of my files (in the Documents Folder)...I did solve this, but now I have another problem. A file of my desktop, for some reason, cannot be copied to an external disk. when a perform a ls -ale o the desktop, the file has the same permissions (and no ACLs) of the other files on the desktop (which I can copy), with the only difference that it lacks a "@" at the end of the permissions string.

"-rw-r--r--@" instead of "-rw-r--r-- "

What does the @ stand for and how do I add it?

Many thanks!






Fri Apr 18 11:01:21 2008: Subject:   TonyLawrence


The "@" at the end means it has extended attributes. See "man ls"

See "chflags" and "SetFile" (setfile is in Developer tools) also.

But I'm not sure what's stopping you from copying..



Fri Apr 18 11:22:47 2008: Subject:   TonyLawrence


Actually, after looking at the man pages and playing a bit, I think the "ls" man page is wrong..

I don't know what the "@" means. I have some files that show that, but I don't know why they are different than ones that do not..

ls -@l

(you have to put the l after the @)

shows stuff like this:

drwxrwxrwx 16 apl apl 544 May 17 2007 Adsense
-rw-r--r-- 1 apl apl 8634 Oct 14 2007 Brewster Line.pdf.zip
drwx------+ 39 apl apl 1326 Apr 17 10:58 Desktop
drwx------+ 15 apl apl 510 Apr 7 17:19 Documents
drwx------@ 57 apl apl 1938 Apr 14 13:58 Downloads
com.apple.FinderInfo 32
-rwxr-xr-x@ 1 apl apl 275 Apr 18 07:15 F
com.apple.quarantine 42
-rw-r--r-- 1 apl apl 1067520 Jan 24 10:53 Fprice.xls
drwx------+ 49 apl apl 1666 Mar 21 09:00 Library
drwx------+ 4 apl apl 136 Mar 21 10:19 Movies
drwx------+ 6 apl apl 204 Dec 14 2006 Music
-rwxr-xr-x@ 1 apl apl 275 Jan 2 2007 PageRank
com.apple.quarantine 42

I'm not sure what that means.. has to do with "xattr" but I haven't investigated that..




Fri Apr 18 11:27:23 2008: Subject:   TonyLawrence


Ahh: see this for xattr.

http://arstechnica.com/reviews/os/macosx-10-4.ars/7

I knew you could do that but didn't realize Apple was actually using it for anything - apparently they are.



Fri Apr 18 11:35:08 2008: Subject:   TonyLawrence


So..

Obviously com.apple.quarantine is for downloaded files - the thing that makes the message pop up when you first try to execute something downloaded.

I don't yet know what com.apple.FinderInfo means.. arstechnica says

"(Interestingly, type and creator codes are already (redundantly?) stored this way in Tiger. Assigning them to a file results in a new extended attribute key, com.apple.FinderInfo, with a value that is the concatenation of the type and creator codes. This is done transparently whenever a type or creator code is assigned to a file.)"

but I'm still unclear WHY some of my files have this.

But your un-copyable file has NO "@", right? So it's nothing to do with this..



Fri Apr 18 12:46:00 2008: Subject:   TonyLawrence


Actually, we should start with basics:

Exactly what message do you get when you try to copy?

---

---

Tue Jan 27 20:14:08 2009: Subject: Removing the access list from a file   SamiGuirguis


chmod -N filename

removes all access lists with one shot.



Tue Jan 27 20:19:10 2009: Subject:   TonyLawrence


If I ever knew that, I had forgotten it - thanks!



Mon Mar 16 18:49:59 2009: Subject:   billyverde


I get the following error when I try to add an ACL:

"chmod: Unable to translate group:<group_name> to a UID/GID: Invalid argument"

Happens with all groups I've tried - not a matter of a simple typo in the <group_name>. I've verified that they're all valid group names, ACL is enabled, and I have root access. Anybody know what's up with that?



Mon Mar 16 19:11:14 2009: Subject:   TonyLawrence


You did "sudo fsaclctl -p / -e ", right?

You are doing something like

chmod +a "admin allow delete" foo ??



I can only get that error if I use a non-existent group or user.. $ chmod +a "nosuchgroup allow delete" foo chmod: Unable to translate 'nosuchgroup' to a UID/GID





Mon Mar 16 21:14:44 2009: Subject:   billyverde


Gah... never mind. Syntax error on my part. I'll go sit in a corner now.



Mon Mar 16 21:18:45 2009: Subject:   billyverde


PS. Thanks for the help!



Mon Mar 16 21:29:48 2009: Subject:   TonyLawrence


Just curious - what were you typing?

---

---

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar