POSIX ACL Implementation
ACLs on HDFS have been implemented with the POSIX ACL model. If you have ever used POSIX ACLs on a Linux file system, the HDFS ACLs work the same way.
Compatibility and Enforcement
HDFS can associate an optional ACL with any file or directory. All HDFS operations
that enforce permissions expressed with Permission Bits must also enforce any ACL that
is defined for the file or directory. Any existing logic that bypasses Permission Bits
enforcement also bypasses ACLs. This includes the HDFS super-user and setting
dfs.permissions to "false" in the configuration.
Access Through Multiple User-Facing Endpoints
HDFS supports operations for setting and getting the ACL associated with a file or directory. These operations are accessible through multiple user-facing endpoints. These endpoints include the FsShell CLI, programmatic manipulation through the FileSystem and FileContext classes, WebHDFS, and NFS.
User Feedback: CLI Indicator for ACLs
The ‘+’ symbol is appended to the listed permissions (the output of the ls
-l command) of any file or directory with an associated ACL.
Backward-Compatibility
The implementation of ACLs is backward-compatible with existing usage of Permission
Bits. Changes applied via Permission Bits (i.e., chmod) are also visible as
changes in the ACL. Likewise, changes applied to ACL entries for the base user classes
(Owner, Group, and Others) are also visible as changes in the Permission Bits. In other
words, Permission Bit and ACL operations manipulate a shared model, and the Permission
Bit operations can be considered a subset of the ACL operations.
Low Overhead
The addition of ACLs will not cause a detrimental impact to the consumption of system resources in deployments that choose not to use ACLs. This includes CPU, memory, disk, and network bandwidth.
Using ACLs does impact NameNode performance. It is therefore recommended that you use Permission Bits, if adequate, before using ACLs.
ACL Entry Limits
The number of entries in a single ACL is capped at a maximum of 32. Attempts to add ACL entries over the maximum will fail with a user-facing error. This is done for two reasons: to simplify management, and to limit resource consumption. ACLs with a very high number of entries tend to become difficult to understand, and may indicate that the requirements are better addressed by defining additional groups or users. ACLs with a very high number of entries also require more memory and storage, and take longer to evaluate on each permission check. The number 32 is consistent with the maximum number of ACL entries enforced by the "ext" family of file systems.
Symlinks
Symlinks do not have ACLs of their own. The ACL of a symlink is always seen as the default permissions (777 in Permission Bits). Operations that modify the ACL of a symlink instead modify the ACL of the symlink’s target.
Snapshots
Within a snapshot, all ACLs are frozen at the moment that the snapshot was created. ACL changes in the parent of the snapshot are not applied to the snapshot.
Tooling
Tooling that propagates Permission Bits will not propagate ACLs. This includes the
cp -p shell command and distcp -p.
