|Home » ACP » ACL
Access control lists (ACLs) are an alternate way to control file access. They come 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 as soon as an answer is provided - a 'yes' or 'no' to the type of access requested.
An access control entry has six parts.
- Tag - either user or group.
- ID - the ID of the user or group.
- Verb - either allow or deny.
- Permissions - specific actions to be allowed or denied.
- Flags - four in number, pertain to types of inheritance.
- Inherited - a read-only value denoting if the ACE has been inherited.
Permissions & Flags
ACE permissions and flags are 17 (seventeen) in number.
ACEs can be created, modified. and deleted with ACL.
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 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 five 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 if the file has an ACL. All security fields are accessible and modifiable through the standard ACP framework info sheet.