ACL Tips version 2

Question

Level 4

3,900 points

ACL Tips version 2

The following is a more concise version of my ACL tips post, with some relevant and updated answers for 10.4.4.

Before You Begin: I recommend starting with Mac OS X Server 10.4.3 minimum. Some quirkiness in the ACL model exists in earlier versions of Mac OS X Server 10.4. Also, be sure to check all of your volumes with Disk Utility's Repair function before proceeding. ACL information is stored in the Extended Attributes file, and damage to that file can cause confusion when setting or changing permissions.

The Tiger Permissions Model: Mac OS X Server version 10.4 supports standard UNIX (POSIX) permissions and Access Control Lists (ACLs). ACLs offer some options previously unavailable in earlier versions of the server software, and can be used to define permissions for newly created files and folders. You don't have to use ACLs, though: When disabled, the permissions model simply relies on POSIX permissions, just as with Mac OS X Server 10.3 and earlier. When ACLs are enabled, Mac OS X Server considers ACL information and POSIX information. This consideration process returns the Effective Permissions for a particular file or folder (filesystem object).

The ACL model Apple uses is identical to the model used by Microsoft Windows; however, there is no "ACL only" option that will ignore POSIX permissions. You either have POSIX only (with ACLs disabled), or both (Effective Permissions).

ACLs are enabled on a per-volume basis. You can do so in the Sharing section of Workgroup Manager by clicking the All tab and navigating to an HFS+ volume in the list. Or, you can do so from the command line with fsaclctl.

Effective Permissions: When ACLs are enabled, the Effective Permissions are calculated in the following way:

(relevant POSIX permissions) union (relevant ACL Allow entries) take away (relevant ACL Deny entries)

This means that applicable POSIX permissions (either owner, group, or POSIX everyone) and applicable ACL Allow entries are combined to grant the connecting user access to the filesystem object. If no ACL Deny entries apply to the connecting user, then the Effective Permissions for the user accessing the filesystem object are simply the union of applicable POSIX and ACL Allow entries. If an ACL Deny entry applies to the connecting user, then that level of access is not granted for the filesystem object.

In this way, the ACL Deny entry has the most power. When specified, it overrides any ACL Allow rule or POSIX permission bit.

Applicable POSIX Permissions: The POSIX permissions for a connecting user accessing a filesystem object are determined using the following method. Remember, POSIX permissions are applicable when ACLs are disabled and when they are enabled (as part of the Effective Permissions model).

POSIX permissions consist of three "fields": an owner which must be assigned to a user, a group, and an everyone else category. Sometimes each category is referred to as a POSIX permission bit, and the everyone else field may be referred to as "world," since those are the permissions assigned to any user who cannot be categorized as the filesystem object's owner or group member.

Each POSIX permission field can have zero, one, two, or three of three bits enabled, which determine eight different levels of access: read, write, and execute (for files, launch/open; for folders, view contents). Each is called a bit because together they represent a three-bit number ranging from 0 (binary 000) to 7 (binary 111), where read=4 (binary 100), write=2 (binary 010), and execute=1 (binary 001). As you can see, this allows eight different combinations for eight different access levels:

No access = 0 (000)
Execute only = 1 (001)
Write only = 2 (010)
Write & Execute (Drop Box) = 3 (011)
Read only = 4 (100)
Read & Execute =5 (101)
Read & Write = 6 (110)
Read, Write, and Execute = 7 (111)

If the connecting user is the filesystem object's owner, then he/she receives the POSIX permissions assigned to the owner of the filesystem object. If and only if that fails, then Mac OS X checks to see if the connecting user should be assigned the POSIX permissions assigned to the filesystem object's group. (First it checks to see if the connecting user's primary group matches that of the group assigned to the filesystem object; if there's no match, then it looks up the filesystem object's group to see if the connecting user is a member.) If and only if the group assignment fails, then the connecting user is assigned the POSIX permissions of the everyone else category. If all fail, then no access is returned.

In this way, the POSIX permissions are either those assigned to the owner, group, or everyone else category; if more than one is true for the connecting user, then the first item that is true determines the POSIX permissions returned. In other words, owner overrides group, and group overrides everyone else.

Everyone else doesn't necessarily mean guest. In fact, guest access is only available if it has been enabled for the AFP or SMB services using Server Admin. Often guests do receive the permissions assigned to the everyone else group, unless you use the group named "everyone" (GID 12) in the POSIX group field when assigning it to a filesystem object. Since this is redundant, the "everyone" group is more useful with ACLs.

Setting POSIX Permissions and New File & Folder Behavior: Each filesystem object has three (normally) or four (for special modes) POSIX permission fields attached to it. The permissions for owner, group, and everyone else are often abbreviated using the decimal form of each permission. For example, 773, means owner can read, write, and execute (7), group can do the same, and everyone else can read and execute (drop box) only. An owner name and group name are attached to the filesystem object by the UID and GID of each.

Normally, the POSIX model always applies a default set of permissions calculated by using the umask to newly created files and folders. This is called "standard POSIX behavior" or "standard UNIX behavior". By default the umask is 0022, which means that newly created files receive permissions of 755. The only thing that changes are the owner and group permission field names. The owner is set to the user who created (or duplicated or copied) the file or folder, and the group is set to that user's primary group (which is staff for most users).

You can change the way that the POSIX model applies permissions to newly created files and folders:

* You can set the set-UID or set-GID bits to define a specific owner or group for newly created files. (See man chmod for details.)

* When ACLs are disabled, you can enable the "Inherit Permissions" access option. In this case, the permission fields and bits are inherited from their enclosing folder. This option is disabled with ACLs, because ACLs provide a more robust model for permission inheritance.

continued

Apple Certified System Administrator, AuburnMac; ACN + ACA

Posted on Jan 16, 2006 1:32 AM

Reply

Answer 1

Gerrit DeWitt Author

Level 4

3,900 points

Jan 16, 2006 2:14 AM in response to Gerrit DeWitt

continued

Applicable ACL Permissions: The ACL permissions model creates a tally for all of the Allow and Deny rules that are pertinent to the connecting user. It then passes both tallies to the operating system for use in the Effective Permissions calculation process. These tallies are calculated by taking the union of all applicable entries, thus returning (or denying) the highest level of access to the Effective Permission model.

An ACL can include a virtually unlimited number of entries (sometimes called an Access Control Entry, or ACE), each for a user or group. Each ACL entry is given a type of Allow or Deny, and, unlike POSIX permissions, the system considers all applicable ACEs, not just the first one encountered.

Each ACE can have one or more access controls enabled. There are 17 controls in total; some are specific to files, and others are specific to folders. Each gives certain controls for read, write, administration, or inheritance:

Read:
* readsecurity (Read permissions set for this object)
* readattr (Get Info)
* readextattr (Read extended attributes)
* list (folders only)
* search (folders only)
* read (files only)
* execute (files only)

Write:
* writeattr (Write attributes)
* writeextattr (Write extended attributes)
* delete (Delete this item)
* add_file (folders only; allows creation of a new file therein)
* add_subdirectory (folders only; allows creation of a folder therein)
* delete_child (folders only; allows the folder's contents to be deleted, even if delete is not set for the contents)
* write (files only)
* append (files only)

Administer:
* writesecurity (Change permissions set for this object)
* chown (Change POSIX owner for this object)

Setting ACL Permissions and New File & Folder Behavior: Each filesystem object can have as many or as few ACEs as necessary. The system associates each ACE to a user name or group name via a globally unique ID (GUID).

ACEs do not automatically propagate to children files or folders unless special Inheritance controls are set for each ACE on the parent folder:

* file_inherit (means that newly-created files in this folder will get this ACE)
* directory_inherit (means that newly-created folders in this folder will get this ACE)
* only_inherit (means that this ACE applies to new contents, not to itself)
* limit_inherit (stops inheritance at this object)
* inherited (not really a control, but listed to indicate that this ACE is inherited)

--Gerrit

Reply

Answer 2

Jan 16, 2006 7:16 AM in response to Gerrit DeWitt

thanks for this detailed explanation Gerrit!

however I'm still confused as to what I'm doing wrong or why the ACLs are not working.

With the Groups folder selected in the Share Points pane of Workgroup Manager, I have ACLs enabled on my "Groups" folder and have the owner, group and everyone set to "read & write". In the Access Control List section I have the group "gsc" as an entry of type="Allow", permission="Read & Write", inherited="No", and applies to="This folder. Child files. Child folders. All descendants".

The group "gsc" contains all the users who should have read/write access.

I propogated permissions.

Yet when one of the users who belongs to group gsc creates or edits a file within the share point, it sets them as the owner and prevents others within the group gsc from editing the file. So somehow the ACLs are not working.

What am I not getting?

thanks again.

Reply

Answer 3

Gerrit DeWitt Author

Level 4

3,900 points

Jan 16, 2006 8:06 PM in response to BrianTully

OK, so if you're up-to-date and ready, here's how to do it.

First off:

...when one of the users....creates or edits a file within the share point, it sets them as the owner

As per standard POSIX behavior, this is normal, even when ACLs are enabled. You may have noticed that the file's group is also set to the user's primary group. The POSIX permissions should also still be 755 (owner read, write, execute; everyone else read & execute), unless you've changed the POSIX umask.

With Effective Permissions, both ACLs and POSIX permissions are considered. So, with the previous in mind, here's what I recommend:

1. Reset ACLs using chmod instead of Workgroup Manager. If you want to give the group named "gsc" read and write permissions to a share point at /Volumes/Data/Shared, use the following command:

sudo chmod +a "gsc allow readsecurity,readattr,readextattr,list,serch,read,execute,writeextattr,writeatt r,delete,deletechild,add_file,add_subdirectory,write,append,file_inherit,directoryinherit" /Volumes/Data/Shared

(It doesn't matter in which order you issue the ACL controls, so long as they're each separated by a comma.)

You may wish to first clear all existing ACLs on the folder by issuing the following command repeatedly until you get an error:

chmod -a# 0 /Volumes/Data/Shared

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:

sudo chmod -R +a "gsc allow readsecurity,readattr,readextattr,list,serch,read,execute,writeextattr,writeatt r,delete,deletechild,add_file,add_subdirectory,write,append,file_inherit,directoryinherit" /Volumes/Data/Shared

3. Don't necessarily trust what the Finder's Info or Inspector window lists for permissions. Unfortunately, it does not list Effective Permissions. Instead, actually test the level of access desired for the connecting user. You can also inspect the permissions using ls -el for the directory when logged into the server (or connected via SSH). If your clients are bound to the server's directory domain and authenticate from the login window, then you can use the same command locally. (Otherwise, you'll see masked AFP permissions where the connecting user is mapped to the "owner" of the mount point with 700 POSIX permissions.)

Hope this helps you!

--Gerrit

Reply

Answer 4

Jan 17, 2006 2:22 PM in response to Gerrit DeWitt

thanks SO much for the detailed reponse!!! I really appreciate you taking the time out to help clarify this confusing topic.

i did as you suggested with the ACLs and chmod commands and have now stopped running the "permfix" cron job, so we will see how things go over the next few days. I pray that this is the fix I was looking for.

One other thing...

The chmod commands you shared set the ACL for read-write, correct? If so, what other commands need to be added in order to set them to "full-control"? I read chmod man page and didn't see other ACL options other than what you shared so I'm wondering how "full-control" is achieved.

Also, if I give 2 users "full-control" as defined by an ACE for a shared folder, and one of the users creates a file within the shared folder, does the fact that they have "full-control" mean that any files they create will have the default umask and that the other user wouldn't be able to open it, even though they too have "full-control"?

many thanks again!

Reply

Answer 5

Gerrit DeWitt Author

Level 4

3,900 points

Jan 19, 2006 9:58 PM in response to BrianTully

The chmod commands you shared set the ACL for read-write, correct? Correct. The command listed in the last post will apply read & write controls for the gsc group, adding file and folder inheritance to any newly-created enclosed objects. To set full control, you simply need to add two more controls to the list: chown and writesecurity:

sudo chmod +a "gsc allow readsecurity,readattr,readextattr,list,serch,read,execute,writeextattr,writeatt r,delete,deletechild,add_file,add_subdirectory,write,append,file_inherit,directoryinherit,chown,writesecurity" /Volumes/Data/Shared

The major difference between all read and write controls and the full control set of controls is that full control would enable your gsc group to dynamically change permissions for any files onto which its ACL entry allows it, along with the ability to change the file's POSIX owner (which is less important, unless you want to change the user who originally created/copied the file in/to the folder).

Also, if I give 2 users "full-control" as defined by an ACE for a shared folder, and one of the users creates a file within the shared folder, does the fact that they have "full-control" mean that any files they create will have the default umask and that the other user wouldn't be able to open it, even though they too have "full-control"?

As long as both users have full control to the file or folder in question, it doesn't matter what POSIX permissions are returned. The POSIX owner, group, and permissions don't have to be set such that one is the owner. Remember that Effective permissions take POSIX permissions and ACLs into consideration. In fact, POSIX access could be set to 000, returning no access, so long as an ACL for full control is present (and no ACL deny rules apply), the user or group would have full control.

New files created in a folder will still have their owners set to the creating user, their groups set to the creator's primary group, and their permissions set as per the umask (resulting in 755 by default). However, these are all POSIX permission model items, and that's just 1/3 of the Effective Permissions picture. If the enclosing folder has an ACL entry with inheritance that grants a specific user or group access, then that ACL will be inherited to the newly-created file, regardless of who creates it.

Let's say that /Volumes/Data/Shared has the full control ACL for gsc set with inheritance as specified in my last command. Let's say that Sally and Bob are members of the gsc group. Both have their primary groups set to Users (staff), which is the default.

Bob then creates a new file in (or copies a new file into) /Volumes/Data/Shared: "bob-file.txt" The permissions for /Volumes/Data/Shared/bob-file.txt will show the following: owner: Bob, group: staff, POSIX permissions: 755, ACL for gsc allows full control for that group. Thus, Sally has full control for bob-file.txt, even though she isn't the file's owner.

However, if you've omitted the file_inherit (or directory_inherit) control for the /Volumes/Data/Shared folder, the situation changes. Any file that Bob creates will not have an ACL entry inherited. Thus, even though both Bob and Sally have full control (as granted by the ACL entry for the gsc group) for the /Volumes/Data/Shared folder, the file bob-file.txt will be read-only for Sally. (Sally can still duplicate or delete it since she has full control for its parent folder, but she cannot simply double-click it and modify it. Read/write control would grant her that ability, too.)

The ability to change permissions and ownership comes with full control. This operates independently from inheritance, and I recommend using full control with caution, as each user with that ability can modify permissions from their default inherited ACL entries, potentially taking away permissions for other users. Full control for a folder allows the user/group to be an "administrator" for that folder.

--Gerrit

Reply

Answer 6

Jan 20, 2006 6:43 AM in response to Gerrit DeWitt

Gerrit, you are brilliant! Thanks again for such a clear and concise explanation.

I'm glad to see that my assumptions about how ACLs work were not too far off-base. I think the Terminal commands you shared somehow work better than Workgroup Manager.

One last question and I promise I won't bother you again 😉

How do ACLs deal with "locked" files, i.e., files whose file flags are set to "uchg" by applications such as Dreamweaver (and its simple check-in/check-out function)?

If a user belongs to the "gsc" group and has read-write defined in the ACL, will they be able to "unlock" the file if Dreamweaver locked it for another user? I'm assuming what Dreamweaver does is that it changes the file flag to uchg for the user who checks in the file. But when another user needs to check out the file they are not able to edit it due to it being locked.

Do ACLs have any control over the file flags?

Reply

Answer 7

Jan 31, 2006 9:27 AM in response to BrianTully

Is this what I should be doing? Using ACL's?

All I did was update our server from 10.3.9 to 10.4.4. Now, like many, group permissions are not carried over to new files and folders and I am constantly doing "chmod -R" and "chown -R" to fix permissions for everyone.

I noticed that the "Inherit permissions from parent" on the share points is grayed out. Even if I trash the sharepoint and recreate it, it is still not an option. So Apple is giving us no choice but to implement ACLs???

Thanks for the in-depth details on the ACL creation. A little further explanation for me would be a great help.

Thanks in advance.

Reply

Answer 8

Rich74

Level 3

949 points

Feb 2, 2006 2:57 AM in response to Gerrit DeWitt

Hello

I've been posting lengthy descriptions of my issue left, right and center, but I think it might be too much info. Here's the concise version:

Users from 'group1' with network home folders stored on 'volume2' do not receive ACE permissions at all whereas users from 'group1' with homes on 'volume1' do. Both volumes have ACLs enabled. The folder utilising ACLs is on 'volume1' in the same directory as the home folders. It is added to the user's docks via MCX machine prefs, using WGM on a client machine to navigate to 'volume1/homes/sharedfolder' and adding it to dock prefs.

Effective permissions says all users receive correct ACE enforced permissions.
Terminal ls -le for shared folder lists correct permissions for groups.

The problem seems to be volume related.

Thanks anyone 🙂

Reply

Answer 9

Feb 8, 2006 8:44 AM in response to Gerrit DeWitt

I have a question re: file inheritance. Last year I set up a fairly complex GroupShare folder for my middle school under OSX Server 10.3, following procedures recommended by John DeTroye's Tips and Tricks. Inside the "GroupShare" sharepoint, I created folders for each one of my school's houses, and then in each of those folders I created folders for each teacher, and I created a drop box inside of each teacher's folder. Teachers have ownership of everything in their folder: students (group = CWStudents) have read only access to the contents, write only for the drop boxes.

This scheme worked wonderfully well until we upgraded to Server v. 10.4.4. File inheritance no longer works- when students drop files into a teacher's drop box, teachers can't open them. Some teachers also had set up folders for students to use to share files with eachother- this no longer works either.

I tried turning off ACLs for the volume, and enabling File Inheritance for the GroupShare sharepoint in WorkGroup Manager- but that didn't work- File Inheritance didn't propagate down to all the subfolders.

After reading through these Tips, it is obvious that I need to enable ACLs and use them. However, as a teacher I don't have time to go through and re-set up ACLs for all the sub directories on my GroupShare sharepoint.

My question: can I use the file_inherit and directory_inherit commands to turn on file inheritance for the entire GroupShare sharepoint, without having to set up ACLs for each subfolder? If so, what do I type in terminal? I'm not a technician- just a teacher who is pretty good at following directions. I'd appreciate any help you all could give me.

Thanks,
David

Mac OS X (10.4.4)

Reply

Answer 10

Rich74

Level 3

949 points

Feb 9, 2006 1:06 AM in response to Rich74

http://discussions.apple.com/thread.jspa?threadID=353975

Solved the volume/ACL issue I had.

Reply

Answer 11

Rich74

Level 3

949 points

Feb 9, 2006 1:15 AM in response to David Manolis1

Maybe try enabling ACLs on the volumes you're using via the terminal just to be sure, then restart the server...

sudo /usr/sbin/fsaclctl -p / this is the path to the volume -e

You shouldn't get any error/syntax messages in terminal, just a fresh prompt.

Also, try flushing the caches on your client machines with this:

sudo rm -r ~/Library/Caches/*;sudo rm -r /Library/Caches/*;sudo rm -r /System/Library/Caches/

You can send it with Remote Desktop or (per client) use Maintenance http://www.jessehogie.com/ (downloads). MainMenu is good too http://www.santasw.com/products.html

Reply

Answer 12

Feb 14, 2006 7:12 AM in response to Gerrit DeWitt

First of all. Gerrit, thank you so much for sharing all your knowlege about ACLs with us! I really appreiciate your tips. Finally I understand how to use and control ACLs.

b. You could add the -R argument to apply permissions recursively throughout the existing contents of the Shared folder:

I would like to add something I found useful. If you have just activated ACL on your volume, and want the folders/files inside a specific folder you are recursively adding ACLs to, to appear as inherited, just ad the i parameter to your command.

From the chmod man page:
The +ai# mode may be used to insert inherited entries at a specific location. Note that these modes allow non-canonical ACL ordering to be constructed.

sudo chmod -R +ai "gsc allow readsecurity,readattr,readextattr,list,serch,read,execute,writeextattr,writeatt r,delete,deletechild,add_file,add_subdirectory,write,append,file_inherit,directoryinherit" /Volumes/Data/Shared

I really like the possibillity of allowing users to create files and folders, but preventing them from deleting them. If you for example have a folder with a lot of sub-folders inside, and you want to make sure that nobody by accident deletes that parent folder, you can uncheck the "delete" checkbox inside "Write" in the ACE. Users can still delete sub-folders, but you have a little extra security on the parent folder. Pretty neet! 🙂

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 13

Feb 15, 2006 2:43 PM in response to Gerrit DeWitt

Your ACL info was great but I can't seem to get it working. I simply want the group RW permissions to propagate to new files created on the share. The news office I support needs for everyone to be able to overwrite files. I've tried enabling the AFP inherit flag but it didn't do anything either. Here is the share in question:

drwxrwx--- + 45 jms0023 CAS\dail 1530 Feb 15 16:36 DailyEd

I did the following:

chmod -a# 0 /Volumes/NTDaily/DailyEd
chmod -a# 0 /Volumes/NTDaily/DailyEd/
chmod: No ACL present: Invalid argument

then....

xserve:/Volumes/NTDaily/DailyEd root# sudo chmod +a "CAS\dailyed allow readsecurity,readattr,readextattr,list,search,read,execute,writeextattr,writeat tr,delete,delete child,add_file,add_subdirectory,write,append,file_inherit,directoryinherit" /Volumes/NTDaily/DailyEd

then I create a new Word doc at the root level of the volume.

-rw-r--r-- + 1 trent CAS\dail 19456 Feb 15 16:36 trent2222.doc

It still can't be edited by the group. Any ideas? Thanks.

This is 10.4.4 Server on an Xserve G5 BTW.

Reply

Answer 14

Feb 16, 2006 11:30 AM in response to Trent Geerdes

I also get this when running fsaclctl.

fsaclctl -p /Volumes/NTDaily/DailyEd
error (-1) from /Volumes/NTDaily/DailyEd. (Unknown error: -1). Support for access control lists is unkown.
error (-1) from /Volumes/NTDaily/DailyEd. (Unknown error: -1

Reply

Answer 15

MacSEK

Level 1

10 points

Feb 23, 2006 2:41 AM in response to Gerrit DeWitt

Hi there,

through a problem with office documents in combination with home directories stored on an afp sharepoint in another thread, i started to work with ACLs. I also appreciate that Gerrit shares his knowledge about ACL so i hope he - or anybody else - can help me with my problem:

this is what i did:

first of all, i need the following user permissions (after the POSIX rights union with ACL rights):
owner r/w
group r/w
everybody -/-

guest access is dieabled.

So i set up a test-volume and activated the ACLs. (Screenshots are available over the links - sorry the are in German)
http://www.thomashecker.de/aclaktiviert.jpg

The i set up the rights i need (like shown above):
http://www.thomashecker.de/aclzugriff.jpg

Here you have the details:
http://www.thomashecker.de/rechtedetail.jpg

The configuration of AFP looks like this:
http://www.thomashecker.de/afpmitacl.jpg

With this configuration everything should work fine, and the way i need, but it does not:

1.) die permissions are only handed down to other folders, not to files
2.) new created files still have the standard posix rights (owner r/w group r/- everybody r/-)
3.) only the owner of the file can change file attributes
4.) only the owner of the file can change the label of a file

So is there anything i did wrong, or does the acl-thing not work yet?

Thanks for help
MacSEK

Reply