ACL Tips

Question

Level 4

3,900 points

ACL Tips

These are my suggestions for reliable ACL permission behavior with Mac OS X Server 10.4, based on several servers that I manage and have migrated to Tiger Server since May. I hope that you find these tips useful!

Order of Operations for Permissions
ACL entries almost always override POSIX permissions. When determining a user's access to a file or folder, Mac OS X will give the user access in the following way:

1. ACL Permissions Model: Deny or Allow
ACL entries are listed and consulted in a whole-number numerical fashion starting with 0,1,2, and so forth.

Deny rules will always have lower numbers than allow rules, so every deny rule is evaluated first. If a deny rule is encountered, the permissions model ignores POSIX permissions and rejects access for the connecting user.

If an allow rule is encountered, Mac OS X continues down the ACL list, "adding" applicable allow rules for the user and his or her group memberships by GUID, taking the union of all the ACL rules that apply to him or her.

2. POSIX Model
The POSIX model is consulted only if there is no ACL deny rule for the connecting user (e.g., no applicable ACLs encountered, only applicable ACLs encountered, no ACLs set for share point).

a. POSIX Owner - If the user attempting to access the filesystem object (folder/file) is the POSIX owner, he or she is granted the permissions of same.

b. POSIX Primary Group - If the group GID for the filesystem object is the primary group GID of the user accessing the object, then he or she gets permissions assigned to the group.

c. POSIX Member of the object's group - If the group of the filesystem object is not the primary group of the user accessing the object, then the user's additional group GID memberships are consulted. If one such GID matches the GID of the object's group, then the user gets permissions associated with that group.

d. POSIX Everyone permissions - As a last resort, the user gets these permissions. If guest access is enabled and POSIX access is consulted, guests will get these permissions*.

Effective Permissions
Finally, Mac OS X gives access to the resource based on the union of the ACL permissions returned (which itself is a union of relevant ACL entries) and the POSIX permissions as they apply to the user. Here are examples:

1. Deny Rule - As mentioned above, if tim attempts to connect and an ACL deny entry is in place for tim (or a group that contains tim), Mac OS X stops evaluating ACL rules and denies access. It also disregards POSIX permissions that may apply to tim.

2. Allow Rule - Suppose jill is a member of the group staff and the share point "shared" has the following ACL entries and POSIX permissions. For now, we'll keep the ACL permissions to simple POSIX-like read and write.

ACL #0 Deny user tim read, write
ACL #1 Allow user jill read, write
ACL #2 Allow group staff read only
ACL #3 Allow group admin read,write
Owner root can read and write
Group admin can read only
Everyone can read only

When jill connects to "shared," Mac OS X evaluates permissions: ACL #0 does not apply to jill. ACL #1 gives jill read & write access. ACL #2 gives jill read access (since jill is a member of staff). ACL #3 does not apply to jill. Thus, the ACL permissions returned for jill is (read & write) union with (read), which gives read & write ACL access. Now, POSIX permissions are consulted. Jill isn't the owner. Jill's primary group isn't admin, and jill is not a member of the group admin. Thus, jill gets the everyone permissions of read only. Now, Mac OS X adds the ACL permissions to the POSIX permissions for jill: (read & write) union with read = read & write. Thus, as you'd expect, jill can read & write to the "shared" folder.

--Gerrit DeWitt
Apple Certified System Administrator

Posted on Jul 19, 2005 4:17 PM

Reply

Answer 1

Gerrit DeWitt Author

Level 4

3,900 points

Jul 19, 2005 4:26 PM in response to Gerrit DeWitt

* Mac OS X 10.4 also has an everyone group (GID 12 in the server's local NetInfo domain), with memberships calculated by the operating system. This group can be used with an ACL entry to give guest users privileges via an ACL entry instead of via the POSIX Everyone bit.

Of course, just as with any other user, ACL permissions will be "added to" (union) the POSIX permissions, so Everyone still plays a role.

Just remember that "unioning" permissions always returns the highest-level of access for the user.

Reply

Answer 2

Gerrit DeWitt Author

Level 4

3,900 points

Jul 19, 2005 4:35 PM in response to Gerrit DeWitt

To keep things simple, I usually follow these practices when configuring share points. This is by no means mandatory, as ACL access offers several combinations for control!

1. For user home directories, don't use ACLs. The standard POSIX permissions will work. (Keeping homes on ACL-enabled volumes is fine, just as long as the POSIX permissions for the home are set correctly.)

2. Don't expect the Inherit Permissions model to work with POSIX access. This is the "Inherit Permissions from Parent" radio button in the AFP Settings part of the Access tab. Just keep it on "Standard POSIX behavior." Sadly, this worked in Panther Server, but was broken in 10.4 and 10.4.1; many report trouble with 10.4.2 as well. Fortunately, using ACLs is a good alternative.

3. For "collaborative" share points (where some users read only and others read and write), use ACLs, but set the POSIX permissions such that these users get no access. This keeps troubleshooting simpler as access is governed by the ACLs alone.

4. Remember that the union with any permission with no access is that permission, as the union returns the highest-level of access given. Think of the union of a list of permissions (ACL entries and POSIX) as the answer to the question, "What is the highest-level of access we can grant to the user given applicable ACLs and POSIX bits?" The only way a user will get no access is if you either: (1) use an ACL deny rule, or (2) make sure that all ACL entries and POSIX bits return "no access" for the connecting user.

Reply

Answer 3

Gerrit DeWitt Author

Level 4

3,900 points

Jul 20, 2005 8:57 PM in response to Gerrit DeWitt

Enabling ACLs from the command-line

You can enable ACLs on the destination volume whose filesystem is at least HFS+ (Mac OS Extended) with the following command. Mac OS Extended (Journaled) or Mac OS Extended (Case-sensitive, Journaled) is highly recommended, though.

fsaclctl -p <path to volume> -e

For more, see "man fsaclctl" or these pages:

http://arstechnica.com/reviews/os/macosx-10.4.ars/8

http://www.macosxhints.com/article.php?story=2005050120073947&query=acls

Reply

Answer 4

Gerrit DeWitt Author

Level 4

3,900 points

Aug 14, 2005 7:32 PM in response to Gerrit DeWitt

Access Control Lists support 21 unique access controls for filesystem object behavior. Some modes are unique to folders or unique to files. Others are common to both.

The access controls which can be broken down into four categories: Read, Write, Inherit, and Administer.

Controls for Folders & Files (9)

Read category: 1. readattr (Read Attributes, such as file information), 2. readextattr (Read Extended Attributes, such as Spotlight metadata), and 3. readsecurity (Read Security, or view assigned permissions)

Write category: 1. writeattr (Write Attributes), 2. writeextattr (Write Extended Attributes), and 3. delete (Delete This Item)

Inheritance category: only_inherit (Serves to indicate that ACL permissions were inherited from the enclosing folder. See the Folders Only Inheritance category for more.)

Administer category: 1. writesecurity (Change Permissions) and 2. chown (Change Owner)

Controls for Files Only (4)
In addition to those for folders and files...

Read category: 1. read (Open for reading) and 2. execute (Execute/Launch)

Write category: 1. write (Open for writing) and 2. append (Open for writing ONLY additional information to the file)

Controls for Folders Only (8)
In addition to controls for folders and files...

Read category: 1. list (Show folder contents) and 2. search (Search for files by name)

Write category: 1. delete_child (Delete this folder's contents. Overrides the delete option for an enclosed subfolder or file within this folder.), 2. add_file (Save or copy files to this folder), and 3. add_subdirectory (Create new folders in this folder)

Inheritance category: 1. file_inherit (Applies this folder's ACLs forward to newly-created enclosed files - those saved or copied to this folder. Such new files will get the only_inherit control appended to the inherited ACLs from the parent to indicate same.), 2. directory_inherit (Applies this folder's ACLs forward to newly-created or copied folders within this folder. Such new folders get the only_inherit control added to the inherited ACLs to indicate that the privileges are inherited.), and 3. limit_inherit (Stops inheritance at this subfolder so than new ACLs can be used.)

--Gerrit

Reply

Answer 5

Gerrit DeWitt Author

Level 4

3,900 points

Nov 4, 2005 11:29 AM in response to Gerrit DeWitt

With the Mac OS X 10.4.2 and 10.4.3 updates, Apple has greatly improved how ACLs work. However, if you applied any access controls using Mac OS X Server 10.4 or 10.4.1, you may encounter errors when trying to remove or modify them via the Terminal using chmod.

For example, an ls -el may clearly list several ACL entries but manipulation with chmod returns an error like "cannot translate qualifier on ACL" or "no ACL present."

In this case, log in as an admin user on your server and use Disk Utility to repair the volume structure of the volume that contains the troublesome ACL entries. I recommend stopping all file and print services so that Disk Utility can unmount and repair the volume, if necessary. Likely the volume's Extended Attributes file, which holds ACL and metadata information, will need to be repaired.

Alternatively, you could stop file and print services and repair the volume using diskutil via the command-line (locally, or via SSH):

diskutil repairVolume /Volumes/<disk name>

--Gerrit

Reply

Answer 6

Jan 10, 2006 12:03 PM in response to Gerrit DeWitt

Gerrit, thanks for your comments, especially the Disk Utility check.

I would like to add that if you can't get ACLs to stick you really need to examine them from the command prompt, rather than relying on Workgroup Manager.

To do this, open the Terminal and change to the directory that contains the folder on which you have created some ACLs.

cd /pathtofolder

then

ls -le

You should see the ACLs.

Frequently I have seen ACLs listed in Workgroup Manager but not in the Terminal. If this is happening, try creating the ACLs via the Terminal. For instructions look in Terminal then type

man chmod

But essentially its

sudo chmod +a "user-or-group allow typeofpermission" /pathtofolder.

A few examples...

sudo chmod +a "admin allow list,search,add file,add_subdirectory,deletechild" /folder

sudo chmod +a "admin allow write, append, read" file

sudo chmod +a "admin allow file_inherit" /folder

Once you have done that, check again with ls -le to see the permissions are in existance.

Then have a look in Workgroup Manager. All good? Now try modifying the ACLs using Workgroup Manager. I have seen on a number of occasions the new permissions appear in Workgroup Manager, but when you examine in the Terminal all the ACLs have been erased.

One final problem that I have seen is if type ls -le and then you drag the folder into the Terminal to complete the path, the ACLs show up blank. However if you explicitly type the path in the Terminal they are displayed correctly.

ACLs are a complete mess.And after 6 months of Tiger it is my opinion they really ought not to be. I've just spent a VERY frustrating day trying to sort out permissions problem on 10.4.3 Server with shares on a software RAID 1 drive.

Dual XServe Mac OS X (10.4.3) Server shares are on a software RAID.

PowerMac G4/733

PowerMac G4/733

Reply

Answer 7

Feb 14, 2006 8:44 AM in response to Clive Sweeting

I'm running into an issue with the sudo chmod+a "user-or-group allow type of permission" /pathtofolder command. I set the group acl thru workgroup manager, but it doesn't propagate changes to existing folders or files, so I went command line. However, when I try this, it uses the user name, not the group name. In this case www. How do I specify the group www from the command line?

Reply

Answer 8

Feb 14, 2006 2:44 PM in response to Niels Meersschaert

Your question is answered in ACL Tips version 2 ... 🙂

Gerrit wrote:
2. Note that file_inherit and directory_inherit will apply to new files and folders created inside of the /Volumes/Data/Shared folder. If you want to apply permissions to existing items, you have some options:
a. You could simply duplicate the contents of the Shared folder and delete the originals. The duplicates would be newly created files/folders and would inherit the ACE for the gsc group from Shared.
b. You could add the -R argument to apply permissions recursively throughout the existing contents of the Shared folder...

Power Mac G5 Dual 2.5GHz, 2GB RAM, 570GB HD, ATI Radeon 9600XT Mac OS X (10.4.4) 20-inch Cinema Display

Reply

Answer 9

Feb 24, 2006 12:04 PM in response to Thomas Berglund

I saw the -R & used that, however my point was the owner used the user with that name, not the group with that name. Since on Tiger there is both a www user & www group, this can create problems if I want to apply the settings to the group, not the user. I can't find a syntax to specify group over user when both have the same name. Any ideas?

Reply

Answer 10

Gerrit DeWitt Author

Level 4

3,900 points

Mar 5, 2006 12:33 PM in response to Niels Meersschaert

If you want to change the group name, use chgrp.

--Gerrit

Reply

Answer 11

Mar 12, 2006 8:54 PM in response to Gerrit DeWitt

Gerrit, have read your posts and am making an attempt to absord it all. I am a curriculum technology guy at a middle school and do the network admin because I have to make it work so I can do technology with young teenagers. I used ASIP for years and have moved to Xserve this year, home folders and all that. I am a bit frustrated with Apple, I think there is too much security for some of us, we are just a middle school, not the Bank of America... In any event here is my frustration. I don't use the home folder the way Apple wants me to. Here is what I have done.

Owner: Read write- the student
Group: read write the faculty (not "staff")
Everyone else: none

I want my teachers to be able to access any kid's folder, and to be able to open a file, add a comment and save it back. Well they can't. I would like every folder/file on my server to inheret the parent folders permissions in most cases. What happens now, is the student saves an iMovie lets say. I log on as a faculty member, and can't open the file. As a faculty I have r/w privledges, but not on a newly created file. Many times as faculty I have read only privledges and have to resave the file as a new name, don't want to do that. How can I get the file to inherit the privledges of the parent folder. We are just a middle school and have what I consider simple needs. I don't like the "public" or "shared" folder concept, that is from my days of ASIP. Oh well, any help or direction pointing would be great. Thanks

Reply

Answer 12

Gerrit DeWitt Author

Level 4

3,900 points

Mar 15, 2006 2:22 AM in response to Jeff Peach

There is an easy way to accomplish what you want. And, it's a lot less work than what you're used to doing. 🙂 The only inconvenience is that it you'll need to change your setup, which probably will involve recreation of user homes, since I don't know where your configuration stands now. (You may be able to skip to step 3.)

1. Configure your server as an Open Directory Master. It's not even required that you set up DNS or Kerberos - even though both do have significant advantages. Contrary to popular belief, you can set up an Open Directory Master without Kerberos support; in fact, this is what the Server's Setup Assistant will do automatically. Just keep in mind that your server needs to be on the same subnet as your clients. Otherwise, you will need to configure a DNS name for it and have the server's hostname set to that instead of its "local hostname" (its Bonjour mDNS name).

2. Create a new share point and define it as a home directory share point by creating a mount record for user home directories in the Mount tab. You don't have to utilize all of the features of the network homes for this to work.

Also, ensure that you have ACLs enabled for the volume that houses the home directory share point.

3. Assuming that you already have your teachers in the "teachers" group, add an ACL entry to allow access to the teachers for the home directory share point:

chmod -R +a "teachers allow readattr, readextattr,readsecurity,read,
execute,list,search,writeattr,writeextattr,delete,deletechild,addfile,
addsubdirectory,write,append,file_inherit,directoryinherit" /path-to-share-point

--Gerrit

Reply