GNU Linux/Permissions/POSIX ACLs
- 1 Overview
- 2 Requirements for using ACLs
- 3 ACL Types
- 4 ACL Entries
- 5 Handling ACLs
- 6 Viewing ACLs
- 7 Settings ACLs
- 8 Misc
- 9 TODO
- 10 Mask
- 11 Removing POSIX ACLs
- 12 References
POSIX Access Control Lists (ACLs) allow different permissions for different users or groups to be assigned to files or directories, independent of the original owner or the owning group. This means, in addition to the file owner, the file group, and others, additional users and groups can be granted or denied access by using POSIX ACLs. Said another way, the permissions defined by ACLs are a superset of hte permissions specified by the file permission bits.
Requirements for using ACLs
- Supported by the filesystem used to store content
- The filesystem is mounted with the
- The appropriate package containing the command-line
getfacltools is installed
- the package is named
- the package is named
- Current version of file utils (
mv, etc) with support for working with ACLs
Confirm filesystem is mounted with proper support -
You can use
tune2fs -l /dev/X | grep acl (where X is the device).
sudo tune2fs -l /dev/sdaX | grep acl
Default mount options: user_xattr acl
If it's not there, it would need to be added as a mount option for any filesystem that supports ACLs.
Confirm Kernel has support built-in 
Here we're looking in the @/boot/config-2.6.32-73-server@ kernel config file on an Ubuntu 10.04 LTS server to verify that the kernel was built with ACL support for the filesystem(s) that we're using. In our case we're only using Ext4, but as you can see below this kernel includes support for the other filesystems listed in the conf as well.
$ grep _ACL /boot/config-$(uname -r)
CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_JFS_POSIX_ACL=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_POSIX_ACL=y CONFIG_OCFS2_FS_POSIX_ACL=y CONFIG_BTRFS_FS_POSIX_ACL=y CONFIG_GENERIC_ACL=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_NFS_V3_ACL=y CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3_ACL=y CONFIG_NFS_ACL_SUPPORT=m
Every object can be thought of as having associated with it an ACL that governs the discretionary access to that object; this ACL is referred to as an
access ACL. In addition, a directory may have an associated ACL that governs the initial access ACL for objects created within that directory; this ACL is referred to as a
access ACLsto grant permission to a specific file or directory
default ACLsto set permissions at the directory level for all files in the directory.
If a file inside that directory does not have an ACL, it inherits the permissions of the default ACLs of the directory. access ACLs can override default ACLs
|Type||Man Page Name||Text Form||Description|
||This entry denotes access rights for the file owner.|
||These entries denote access rights for users identified by the entry's qualifier.|
||This entry denotes access rights for the file group.|
||These entries denote access rights for groups identified by the entry's qualifier.|
||This entry denotes the maximum access rights that can be granted by entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP.|
||This entry denotes access rights for processes that do not match any other entry in the ACL.|
When an access check is performed, the ACL_USER_OBJ (owner) and ACL_USER (named user) entries are tested against the effective user ID. The effective group ID, as well as all supplementary group IDs are tested against the ACL_GROUP_OBJ (owning group) and ACL_GROUP (named group) entries.
IBM's Tivoli Storage Manager 
|File System||ACL Support|
setfacl -d -m group:rwx /path/to/your/dir
It appears to be setting the
Default ACL for the
owning group to rwx (octal 777) for a specific directory. Presumably this means that inheritance would push those settings down to any newly created files/directories.
- Q: What about existing files?
- Q: What about existing directories?
mask entry further limits the permissions granted by
named group, and
owning group entries by defining which of the permissions in those entries are
effective and which are masked. 
- If permissions exist in one of the mentioned entries as well as the mask, they are effective.
- Permissions contained only in the mask or only in the actual entry are not effective--meaning the permissions are not granted.
- All permissions defined in the
owning groupentries are always effective.
Removing POSIX ACLs
To remove all the permissions for a user, groups, or others, use the following command :
setfacl -x ACL entry type file
For example, to remove all permissions from the user antony:
setfacl -x u:antony /mnt/gluster/data/test-file
- Support > Product Documentation > Red Hat Storage > 3.0 > Administration Guide > 7.6. POSIX Access Control Lists
- acl(5) - Linux man page
- ACL(Access Control List) Configuration in Debian
- Documentation > Security Guide > Local Security > Chapter 9. Access Control Lists in Linux
- IBM > Tivoli Software > File system and ACL support
- Support > Product Documentation > Red Hat Storage > 2.0 > Administration Guide > 9.5.3. Removing POSIX ACLs