GNU Linux/Permissions/POSIX ACLs

From Wiki
< GNU Linux‎ | Permissions
Revision as of 16:17, 2 March 2015 by Deoren (talk | contribs) (Added a few notes from UNIX and Linux System Administration Handbook, 4th Edition)
Jump to: navigation, search


[1] [2] [3]

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 the permissions specified by the 9-bit UNIX permission model. Read, write and execute permissions are the only capabilities that the ACL system deals with. Additional features such as setuid and sticky bits are handled exclusively through the traditional mode bits.

Requirements for using ACLs

  • Supported by the filesystem used to store content
  • The filesystem is mounted with the acl option
  • The appropriate package containing the command-line setfacl and getfacl tools is installed
    • the package is named acl on Ubuntu
  • Current version of file utils (ls, cp, mv, etc) with support for working with ACLs

Confirm filesystem is mounted with proper support - tune2fs

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 [4]

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)

ACL Types

[2] [1]

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 default ACL.

  • Use access ACLs to grant permission to a specific file or directory
  • Use default ACLs to set permissions at the directory level for all files in the directory

Access ACLs

  •  ?

Default ACLs

[5] [6]

Directories can have a default ACL, which is a special kind of ACL defining the access permissions that objects in the directory inherit when they are created. A default ACL affects both subdirectories and files.

The following are the ways in which the permissions of a directory's default ACLs are passed to the files and subdirectories in it:

  • A subdirectory inherits the default ACLs of the parent directory both as its default ACL and as an access ACL.
  • If a file inside that directory does not have an ACL (already), it inherits the permissions of the default ACLs of the directory as its access ACL.

All system calls that create file system objects use a mode parameter that defines the access permissions for the newly created file system object. If the parent directory does not have a default ACL, the permission bits as defined by the umask are subtracted from the permissions as passed by the mode parameter, with the result being assigned to the new object. If a default ACL exists for the parent directory, the permission bits assigned to the new object correspond to the overlapping portion of the permissions of the mode parameter and those that are defined in the default ACL. The umask is disregarded in this case.


  • An access ACL set for an individual file can override the default ACL permissions
  • You cannot set a default ACL on a regular file (it is intended for directories only to set inheritance)
  • Setting the default ACL on the top-level folder does NOT set the actual permissions for that directory, only those created beneath it.
    • You'll need to explicitly set the ACL entries at the top-most level.

ACL Entries

[5] [2]

Type Man Page Name Text Form Description
Owner ACL_USER_OBJ user::rwx This entry denotes access rights for the file owner.
Named User ACL_USER user:name:rwx These entries denote access rights for users identified by the entry's qualifier.
Owning Group ACL_GROUP_OBJ group::rwx This entry denotes access rights for the file group.
Named Group ACL_GROUP group:name:rwx These entries denote access rights for groups identified by the entry's qualifier.
Mask ACL_MASK mask::rwx This entry denotes the maximum access rights that can be granted by entries of type ACL_USER, ACL_GROUP_OBJ, or ACL_GROUP.
Other ACL_OTHER other::rwx 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.

Correspondence Between Acl Entries And File Permission Bits

[5] [2]

There is a correspondence between the file owner, group, and other permissions and specific ACL entries:

  • The owner permissions correspond to the permissions of the ACL_USER_OBJ (owner) entry.
  • If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. Otherwise, if the ACL has no ACL_MASK entry, the group permissions correspond to the permissions of the ACL_GROUP_OBJ (owning group) entry.
  • The other permissions correspond to the permissions of the ACL_OTHER_OBJ (other) entry.

The file owner, group, and other permissions always match the permissions of the corresponding ACL entry. Modification of the file permission bits results in the modification of the associated ACL entries, and modification of these ACL entries results in the modification of the file permission bits.

Valid ACLs

[5] [2]

  • A valid ACL contains exactly one entry with each of the ACL_USER_OBJ (owner), ACL_GROUP_OBJ (owning group), and ACL_OTHER (other) tag types.
  • Entries with ACL_USER (named user) and ACL_GROUP (named group) tag types may appear zero or more times in an ACL.
  • An ACL that contains entries of ACL_USER (named user) or ACL_GROUP (named group) tag types must contain exactly one entry of the ACL_MASK tag type.
  • If an ACL contains no entries of ACL_USER (named user) or ACL_GROUP (named group) tag types, the ACL_MASK entry is optional.

Viewing ACLs

ACLs are viewed using the getfacl command-line tool.

Setting ACLs


The setfacl utility sets Access Control Lists (ACLs) of files and directories. On the command line, a sequence of commands is followed by a sequence of files (which in turn can be followed by another sequence of commands, ...).

The file owner and processes capable of CAP_FOWNER are granted the right to modify ACLs of a file. This is analogous to the permissions required for accessing the file mode. (On current Linux systems, root is the only user with the CAP_FOWNER capability.)


$ setfacl --help
setfacl 2.2.49 -- set file access control lists
Usage: setfacl [-bkndRLP] { -m|-M|-x|-X ... } file ...
  -m, --modify=acl        modify the current ACL(s) of file(s)
  -M, --modify-file=file  read ACL entries to modify from file
  -x, --remove=acl        remove entries from the ACL(s) of file(s)
  -X, --remove-file=file  read ACL entries to remove from file
  -b, --remove-all        remove all extended ACL entries
  -k, --remove-default    remove the default ACL
      --set=acl           set the ACL of file(s), replacing the current ACL
      --set-file=file     read ACL entries to set from file
      --mask              do recalculate the effective rights mask
  -n, --no-mask           don't recalculate the effective rights mask
  -d, --default           operations apply to the default ACL
  -R, --recursive         recurse into subdirectories
  -L, --logical           logical walk, follow symbolic links
  -P, --physical          physical walk, do not follow symbolic links
      --restore=file      restore ACLs (inverse of `getfacl -R')
      --test              test mode (ACLs are not modified)
  -v, --version           print version and exit
  -h, --help              this help text
  • When using setfacl, you are allowed to use multiple -m (modify) or -x (delete) options on the same line.
  • The options -m, and -x expect an ACL on the command line. Multiple ACL entries are separated by comma characters (','). The options -M, and -X read an ACL from a file or from standard input. The ACL entry format is described in Section ACL ENTRIES.
  • The --set and --set-file options set the ACL of a file or a directory. The previous ACL is replaced. ACL entries for this operation must include permissions.
  • The -m (--modify) and -M (--modify-file) options modify the ACL of a file or directory. ACL entries for this operation must include permissions.
  • The -x (--remove) and -X (--remove-file) options remove ACL entries. It is not an error to remove an entry which does not exist. Only ACL entries without the perms field are accepted as parameters, unless POSIXLY_CORRECT is defined.
  • When reading from files using the -M, and -X options, setfacl accepts the output getfacl produces. There is at most one ACL entry per line. After a Pound sign ('#'), everything up to the end of the line is treated as a comment.
  • If setfacl is used on a file system which does not support ACLs, setfacl operates on the file mode permission bits. If the ACL does not fit completely in the permission bits, setfacl modifies the file mode permission bits to reflect the ACL as closely as possible, writes an error message to standard error, and returns with an exit status greater than 0.


IBM's Tivoli Storage Manager [8]

File System ACL Support


Explain this:

 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?


The mask entry further limits the permissions granted by named user, named group, and owning group entries by defining which of the permissions in those entries are effective and which are masked. [5]

  • 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 owner and owning group entries are always effective.

Removing POSIX ACLs

To remove all the permissions for a user, groups, or others, use the following command [9]:

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


Directly used

Queued up