Access Control Lists
This version of AFP includes support for access control lists (ACLs), which can be enabled on a per volume basis. The inheritance and multiple ownership capabilities of ACLs improve workflow in environments where files and directories require different owners at various phases of work. When ACLs are enabled, computers running Mac OS X are full-fledged peers on Windows networks, which promotes the adoption of XServe as an NT replacement.
When ACLs are enabled for a volume, each file and directory has a security descriptor. A security descriptor includes:
a set of flags, including flags for the discretionary and system ACL (described below), each indicating whether the ACL inherits the settings of the ACLs above it.
an owner SID, similar to the UNIX file owner
a primary group SID, similar to the UNIX file group owner
a discretionary access control list (DACL) that specifies which permissions are granted or denied to which users or groups
a system control list (SACL) that determines which file accesses by which users cause the access to be logged in a security log
Access control entries (ACEs) in the DACLs and SACLs contain the following information:
a SID, specifying the user or group to which the ACE applies
a set of flags, including inheritance flags (listed in Table 1-29) and a flag that applies only to SACL entries
Flag | Description |
|---|---|
| Indicates whether the entry was inherited from a parent ACL. |
| Indicates whether the entry exists only to be propagated to children and is used only when child objects are created or when that entry is changed. If set, the entry is not checked when access or audit checks are done. |
| Indicates whether the entry should be inherited by directories below the object to which the entry applies. |
| Indicates whether the entry should be inherited by files below the object to which the entry applies. |
| Indicates, when the entry is copied to a child, whether the settings of the |
a set of access right bits (listed in Table 1-30); for DACL entries, the access rights bits allow or deny permission; for SACL entries, the access rights bits specifying the types of accesses to be audited
Access right bit | Description |
|---|---|
Generic access rights | The four high-order bits of the access mask format used by securable objects. Each securable object maps these bits to a set of its standard and object-specific access rights. For example, a file object maps the |
| Read, w rite, and execute access |
| Execute access, including |
| Read access, including |
| Write access, including |
Standard access rights | A set of standard access rights that correspond to operations common to most types of securable object. Constants defined for the standard access rights bits include the following: |
| Right to delete the object |
| Right to read the object’s security descriptor, but not including information in the SACL |
| Right for a thread to block until the object is in the “signaled state” |
| Right to modify the DACL in the object’s security descriptor |
| Right to change the object’s owner in the object’s security descriptor |
File and directory access rights | |
| Right to create a file in a directory |
| Right to create a directory in a directory |
| Right to create a directory in a directory (when set for a directory) or to append data to a file (when set for a file) |
| Right to delete a directory and all the files it contains |
| Right to execute a program |
| Right to list the contents of a directory |
| Right to read a file’s DOS attributes, including hidden, read-only, system, and archive attributes. |
| Right to read data from a file or pipe (when set for a file or pipe), or to list the contents of a directory (when set for a directory) |
| Right to read an object’s extended attributes |
| Right to traverse a directory; equivalent to |
| Right to write a file’s attributes. |
| Right to write to a file (when set for a file) or create a file in a directory (when set for a directory); when applied to a directory, this bit is equivalent to |
| Right to write extended attributes |
An ACL can have a mixture of explicitly set and inherited ACEs. When a file or directory is created, ACEs are copied to the new object in the following order:
Explicit ACL entries that deny an SID certain rights
Explicit ACL entries that grant an SID certain rights
Inherited ACL entries that deny an SID certain rights
Inherited ACL entries that grant an SID certain rights
Inherited entries are placed in order in which they are inherited. ACEs inherited from the parent come first, then entries inherited from the grandparent (that is, that the parent inherited and passed on), and so on. As ACEs are processed from first to last, explicit entries override entries inherited from further up the tree.
Inheritance occurs when the object is created and at the time an ACL for a directory is changed, and does not occur at the time that an object is moved into the directory tree. When a folder or file is moved within the volume, its ACL is also moved without change and without updating inherited permissions. Instead, the ACL is updated the next time its permissions are changed, which forces the parent to propagate its permissions.
ACEs in which the CONTAINER_INHERIT_ACE bit or the OBJECT_INHERIT_ACE bit is not set are not copied.
ACEs in which the CONTAINER_INHERIT_ACE bit is set are copied when a directory is created, but not when a file is created. The INHERIT_ONLY_ACE bit is cleared.
ACEs in which the OBJECT_INHERIT_ACE are copied when a file or a directory is created. If copied to a file, the INHERIT_ONLY_ACE bit is cleared. If copied to a directory, the INHERIT_ONLY_ACE bit is set. The intention is to allow directories to give one set of permissions to subdirectories and another set of permissions to files.
The INHERITED_ACE bit is set on all ACEs that are copied.
If the NO_PROPAGATE_INHERIT_ACE bit is set on the entry being copied, the CONTAINER_INHERIT_ACE and OBJECT_INHERIT_ACE bits are cleared in the copy.
When ACLs are enabled for a volume, they are mapped to effective owner, group, and everyone UNIX permissions.
When accessing remote volumes for which ACL is enabled, use the FPAccess command to determine whether the client has access to the file or directory, and use the FPGetACL command to get the ACLs for a file or directory, and the FPSetACL command to set the ACLs for a file or directory.
Last updated: 2006-04-04
  |
||
|
|
|
|
| ||
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |