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 plus symbol (+) is appended to the listed permissions of any file or
directory with an associated ACL. To view, use the ls -l
command.
Backward Compatibility
The implementation of ACLs is backward-compatible with existing usage of
Permission Bits. Changes applied via Permission Bits (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. 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.
