What are ACL’s?

Access Control Lists, abbreviated ACLs, are an additional method to grant specific permissions to certain users. Apple introduced this technology in Mac OS X 10.4 “Tiger”, but it can be found in other Unix® operating systems and Microsoft® Windows as well. ACLs are a supplement to the existing POSIX permissions, so you don’t necessarily need to use ACLs. The conventional rules for access rights still apply, but some optional new rules can be added. Technically seen, an ACL is a list of individual rights which can be attached to a file system object. The ACL can either be empty -in this case, only the conventional POSIX permissions apply-, or it can contain one or more objects called Access Control Entries (ACEs).

An Access Control Entry includes the following information:

• to which users does this entry apply (this can be an individual user or a user group)?
• does this entry allow or deny access?
• which right in particular is allowed or denied, respectively?
• how should this entry be inherited from a folder to the contents of this folder?

 

Individual rights you can specify

ACLs allow the definition of 13 different rights to access a file-system object:

1. read data/list folder contents: the right to read data from a file, or to list the contents of a folder.
2. execute file/traverse folder: the right to execute a file as a program, or -if the object is a folder- the right to traverse this folder to open an enclosed folder.
3. read attributes: the right to read the attributes of a file or folder, e.g. its creation date.
4. read extended attributes: the right to read extended attributes of a file or folder. Whether an attribute is considered to be “extended”, is defined by the vendor of the operating system.
5. read permissions: the right to read the permission settings of a file or folder.
6. write data/create files: the right to write data into a file, or -if the object is a folder- the right to create a new file in the folder.
7. append data/create folders: the right to append additional data to a file, or -if the object is a folder- the right to create a new folder in this folder.
8. write attributes: the right to write attributes of a file or folder, e.g. its creation date.
9. write extended attributes: the right to write extended attributes of a file or folder. Whether an attribute is considered to be “extended”, is defined by the vendor of the operating system.
10. delete: the right to delete this file or folder.
11. delete subfolders and files: if this is a folder, the right to delete enclosed objects.
12. change permissions: the right to change permission settings for this file or folder.
13. change owner: the right to change the owner of this file or folder.

 

These rights can be merged in any possible combination.

 

Settings to control inheritance

Each Access Control Entry is allowed to contain additional information that specifies how this entry is inherited to objects located at deeper levels in the file system hierarchy, for example, a file in a folder which is enclosed in another folder. The top folder may have an ACL which is automatically inherited to objects inside this folder.

Inheritance takes only place when new objects are created. For example, when a file B is created in a folder A, the file B will inherit ACEs from A only at that moment. When somebody changes the permissions of B at a later time, the system will not automatically reinforce a new inheritance from A to B. However, when somebody changes a setting of folder A, and this setting is marked for inheritance, the changes will also apply to the objects that initially inherited settings from A.

  

There are 4 different settings which control how ACE permissions should be inherited:

1. apply inheritance to files: if this option is set, new files will automatically inherit ACE permission settings.
2. apply inheritance to folders: if this option is set, new folders will automatically inherit ACE permission settings.
3. limit to directly contained objects: if this option is set (for a folder), only the objects directly contained in this folder, but not objects at a deeper level (e.g. file in a subfolder of this folder) will inherit ACE permission settings.
4. don’t apply to this folder, but inherit only: if this option is set (for a folder), the ACE should not be applied to the folder itself, but only to the objects that this folder contains.

 

There are 16 possible combinations of these settings, but only 12 of them really make sense in practice.

 

Inherited and explicit settings

Because ACE settings can be inherited from folders to the objects they contain, the system has to keep track which ACEs in an ACL are inherited and which are not. Only ACEs which are not inherited can be changed. Non-inherited entries are called explicit. To change an inherited entry, it is either necessary to change the entry at the parent level where this inherited entry came from, or to delete the ACL for this object (hereby breaking the inheritance), replacing the inherited entries by explicit entries.

How Mac OS X processes Access Control Lists

As mentioned before, an Access Control List consists of several Access Control Entries. Certain rules define how Mac OS X evaluates the entries when a specific user wants to access an object in the file system. Note that ACEs could contradict each other. For example, if user A is allowed to access the file B, but user A is also member of a user group which is denied access to file B, we have a contradiction which must be resolved. The following rules apply:

• The ACEs in the ACL are processed in top-down fashion. All ACEs are respected, the system does not stop at an ACE which somehow “matches” the current user.
• The conventional POSIX permissions are checked after the ACL has been processed. If a file system object has no ACL, only the POSIX permissions apply.
• Entries of the type deny always take precedence over entries of type allow.
• Entries of type allow just add their meanings. If one ACE grants read permission for a particular user, and another ACE in the ACL grants write permission, the user will have both read and write permission.

 

Recommendations

Access Control Lists are a powerful tool to define specific rights at a low granularity. However, you should keep in mind that ACLs are also very complex.

There are 13 different permissions which can be granted or denied, and 12 possible ways to define inheritance. This results in a total of 2^13 * 12 = 98,304 different access rights you can define.

Each of these nearly 100,000 different access rights can be applied to a user or user group to form an ACE, and a nearly unlimited number of ACEs can be combined into an ACL. Each file or folder in your system can be attached to a different ACL, so maintaining all these entries can easily become a nightmare. For this reason you should define ACL permissions with greatest care only.

• Use ACL permissions only when it is necessary, which means only when you have a permission problem which cannot be solved by conventional POSIX settings.
• Use as few user groups as possible. Don’t over-organize your users.
• Avoid to define Access Control Entries for users. Apply ACEs to user groups instead, whenever possible.
• If you want to protect certain files, use POSIX permissions to define very limited access rights, then use as few ACEs as possible to grant permissions to the user groups which should have access.
• Use inheritance whenever possible. If you inherit permissions, you only need to maintain ACLs for a small list of top folders.
• Avoid Access Control Entries of the type “deny”. Denials can easily creat unexpected side-effects. You might inadvertently lose the right to access some objects yourself, or worse, also lose the right to release this restriction.
• Never apply ACLs to parts of Mac OS X, and never try to redefine the access permissions on system files. The computer might become unusable.

 

ACLs in the Finder

The Finder is fully compatible with ACLs. However, it can only display ACLs, not define or alter them. The standard feature to display permissions can be used on ACLs, too:

• Select an object in the Finder.
• Select the menu item File > Get Info, or press Apple+I.
• Open the section Ownership & Permissions in the information panel.

 

File systems supporting ACLs

Access Control Lists can only be used on file systems which are capable of storing them. Mac OS X allows the usage of ACLs for the following types of file systems, if the computers hosting these file systems are using an operating system version compatible with ACLs:

• disk volumes formatted with the Mac OS Extended file system (HFS+),
• network volumes accessed via the Apple Filing Protocol (AFP, AppleShare)
• network volumes accessed via the SMB/CIFS Protocol (Microsoft® Windows).

Other file systems, including disk volumes formatted using UFS, FAT, VFAT, FAT32, or NTFS, and network volumes accessed via NFS, FTP, or WebDAV cannot support Access Control Lists.

 

Enabling or disabling ACL support for local disk volumes

Access Control Lists are consuming a certain amount of storage space, and their usage might also slow down access to files. For this reason, you have to decide if you want to use ACLs on disk volumes or not. By default, Mac OS X will create disk volumes without ACL support when you are installing the standard version, and it will create disk volumes with activated ACL support when you are using Mac OS X Server. TinkerTool System allows you to change the support state for ACLs at any time:

• Open the pane ACL Permissions.
• Select the tab-item ACL Support. Enter your credentials if Mac OS X should ask for them.
• You will see a table listing all locally attached volumes which are theoretically capable of supporting Access Control Lists. To enable ACL support, set a checkmark in the column Supports ACLs. To disable ACL support, remove the checkmark in the respective line.

If you disable ACL support for a volume which had stored Access Control Lists, all lists will be deleted.

Setting POSIX and ACL permissions

To set or modify permissions for a file or folder, select the tab-item Set Permissions.

You can either drag a file or folder from the Finder into the field File or Folder, or you can press the button […] to navigate to a file system object, or enter a BSD path manually. All current permission settings will be displayed in the lower portion of the window.

By pressing the button Users & Groups you can open a drawer which contains all users and groups currently known on your system. This includes users and groups defined in network directory services your computer is bound to.

To specify a new owner or group owner for the selected object, drag a user or group into the respective fields at Standard Permissions. Using the pop-up buttons at the right, you can define the POSIX permissions for the selected object. Choose between Read & Write, Read Only, Write Only, or None.

To add a new Access Control Entry, drag a user or group from the drawer into the table Access Control List. New entries will always be added at the end of the Access Control List. Each line allows you to set the access type to Allow and Deny, and to choose between the predefined permission entries Full Control, Read and Write, Read, and Write. If you want to have access to all 98,304 different settings, select Custom, or press the button Details… at the left, or double-click a line in the table.

If you modify any of the permission settings, the changes don’t become active immediately. They become effective when you press the button Save. You can also go back to the previous state by pressing the button Revert.

To remove an ACE from the ACL, select the respective line in the Table and press the button Delete.

Special operations on the permission settings

Additional operations can be executed by selecting one of the items in the pull-down menu Operations at the bottom of the window. The operations vary depending on whether you have selected a file or a folder.

If you have selected a folder, you can

• remove all Access Control Entries from the ACL which have been inherited from objects at higher levels in the folder hierarchy,
• convert all inherited entries into explicit entries,
• propagate the current settings into all objects contained in this folder. This includes objects at all deeper levels (e.g. files in a subfolder of the folder). TinkerTool System will ask what settings you want to propagate. You can propagate any combination of owner entry, group entry, • owner permissions, group permissions, everyone permissions, and Access Control List. This will reset all selected permission settings on all objects enclosed in that folder.

If you have selected a file, you can either

• remove all entries of the Access Control List,
• or re-apply the inheritance of entries onto this file in case you have removed or altered the ACL by some of the other operations.

Removing all entries of an Access Control List does not erase the Access Control List. It just creates an empty one, which needs a bit more storage space than a “non-exisiting” ACL. Mac OS X does not support the complete removal of an ACL. So if you attach an ACL to an object, the object will always keep the ACL storage space during its whole lifetime.

Displaying effective permission settings

The combination of several ACEs and the POSIX permissions for an object can make it sometimes difficult to judge how the final rights for a particular user will come out. For this reason, you can display the effective access permissions, a selected user has for a selected file system object.

• Select the tab-item Effective Permissions.
• Drag a file or folder into the field at the top, or press the button […] to navigate to an object, or enter a BSD path manually.
• Drag a user from the users drawer into the field User. You can open the drawer by pressing the button Users & Groups.

The table Effective Access Rights will list the permissions. Granted rights appear with a checkmark and in bold type, denied rights are displayed without a checkmark in regular type.