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
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
