Access control entries (ACEs) in OS X Server

An ACE is an entry in an access control list (ACL) that specifies, for a group or a user, access permissions to a file or folder and the rules of inheritance.

Explicit and inherited ACEs

The Server app supports two types of ACEs:

Explicit ACEs, which are those you create in an ACL. For more information, see Set folder access permissions.
Inherited ACEs, which are ACEs you created for a parent folder that were inherited by a descendant file or folder.

Note: Inherited ACEs cannot be edited unless you make them explicit.

Understand inheritance

ACL inheritance lets you specify how permissions pass from a folder to its descendants.

The Apple ACL inheritance model

The Apple ACL inheritance model defines four options that you select or deselect in the Server app to control the application of ACEs (in other words, how to propagate permissions through a folder hierarchy):

Inheritance option	Description
Apply to this folder	Apply Administration, Read, and Write permissions to this folder.
Apply to child folders.	Apply permissions to subfolders.
Apply to child files	Apply permissions to the files in this folder
Apply to all descendants	If you want an ACE to apply to all descendants without exception, you must select the “Apply to child folders” and “Apply to child files” options in addition to this option.

OS X propagates ACL permissions at two well-defined times:

At file or folder creation time—when you create a file or folder, the kernel determines what permissions the file or folder inherits from its parent folder.
When initiated by administrator tools—for example, when using the Propagate Permissions option in the Server app.

The following figure shows how the Server app propagates two ACEs (managers and design_team) after ACE creation. Bold text represents an explicit ACE and regular text represents an inherited ACE.

Diagram shows Jupiter folder has explicit “managers” ACL entry, which is inherited by all its descendant folders and files. Jupiter’s gread-grandchild folder also has “lander team” ACL entry, which its child inherits. Another child folder of Jupiter has “design team” ACL entry, which its child inherits.

ACL inheritance combination

When you set inheritance options for an ACE in the Server app, you can choose from 12 unique inheritance combinations for propagating ACL permissions.

Inheritance Apply to this folder Apply to child files Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants
Inheritance Apply to this folder Apply to child folders Apply to child files Apply to all descendants

ACL permission propagation

The Server app lets you force the propagation of ACLs. Although propagation is done automatically by the Server app, there are cases when you might want to manually propagate permissions:

You can propagate permissions to handle exceptions. For example, you might want ACLs to apply to all descendants except for a subtree of your folder hierarchy. In this case, you define ACEs for the root folder and set them to propagate to descendants. Then, you select the root folder of the subtree and propagate permissions to remove the ACLs from descendants of that subtree.
In the following example, the items in white had their ACLs removed by manually propagating ACLs.
You can propagate permissions to reapply inheritance in cases where you removed a folder’s ACLs and decided to reapply them.
You can propagate permissions to clear all ACLs at once instead of going through a folder hierarchy and manually removing ACEs.
When you propagate permissions, the permissions of bundles and root-owned files and folders aren’t changed.

For more information about how to manually propagate permissions, see Propagate access permissions.

Rules of precedence

OS X uses the following rules to control access to files and folders:

Without ACEs, POSIX permissions apply. If a file or folder has no ACEs defined for it, OS X applies standard POSIX permissions.
With ACEs, order is important. If a file or folder has ACEs defined for it, OS X starts with the first ACE in the ACL and works its way down the list until the requested permission is satisfied or denied.
You can change the ACE order from the command line using the chmod command.
Allow permissions are cumulative. When evaluating Allow permissions for a user in an ACL, OS X defines the user’s permissions as the union of all permissions assigned to the user, including standard POSIX permissions.

OS X evaluates ACEs in the ACL to determine a user’s access. If ACEs are present for the user in the ACL, the user is granted or denied access. If no ACEs are present for the user in the ACL, OS X evaluates the standard POSIX permissions defined for the file or folder to grant or deny access.