|Home » ACP » ACL
Access control lists (ACLs) are an alternate way to control file access. They come to OS X via the FreeBSD distribution where they very likely were inspired by Dave Cutler's security system for what became NT Server.
ACLs provide more granularity for access control than the traditional Unix 'read/write/execute'. But they're not an entity unto themselves - 'computer within a computer' - but rather indicators to how the file system will deal with access requests. It's up to the file system to determine how they're to be observed.
An access control list is a list of access control entries. The file system looks at these entries each time a user makes a request for access to a file. Access control entries are read in the order given and parsing terminates soon as an answer is provided - a 'yes' or 'no' to the type of access requested.
An access control entry on OS X has six parts.
- Tag - this is either user or group.
- ID - the ID of the user or group targeted.
- Verb - this is either allow or deny.
- Permissions - the specific actions to be allowed or denied.
- Flags - these are four in number and pertain to types of inheritance.
- Inherited - this is a read-only value denoting if the ACE has been inherited.
Permissions & Flags
ACE permissions and flag are 17 (seventeen) in number.
ACEs can be modified and deleted with ACL; new ACEs can also be created and placed at a specified index.
No attempt is made to 'merge' ACEs - all ACEs are exactly as you specify them.
ACL is a powerful tool to be used to troubleshoot user systems rather than build up potentially chaotic security models. Attempts to create wired schemes to supersede basic file permissions can be dangerous; Cutler used ACLs because he'd already been familiar with building file servers and Microsoft didn't have a permissions system to speak of. Administrators could find them helpful but they have to really know what they're doing.
Of course everything depends on how the file system treats ACLs. Apple's file systems give priority to ACLs over permission sets (but not over file flags). Sorting things out in this quagmire can be a nightmare.
ACLs on OS X don't seem to pertain to specific inodes (CNIDs) but to specific paths. Copying or moving a file hive seems to strip it of its ACLs.
Apple started using ACLs instead of file flags to protect important directories under root in 10.6 where they'd previously used file flags. The advantage isn't obvious as none of the ACLs are inherited and file flags are theoretically more powerful in those situations.
ACL's basic layout uses file columns of data in the upper view, all related to file system security.
- Name - the name of the file.
- Owner - the file's owner.
- Group - the file's group.
- Mode - the file's mode in octal.
- Flags - the file flags in hexadecimal.
Field 1 is rendered in bold and fields 2-5 are rendered in an 'alternate' colour if the file has an ACL. All security fields are accessible and modifiable through the standard ACP framework info sheet.