Difference between revisions of "GNU Linux/Permissions/POSIX ACLs"

From WhyAskWhy.org Wiki
Jump to: navigation, search
m (Added a few notes from UNIX and Linux System Administration Handbook, 4th Edition)
m (Incorporated info from Arch Linux wiki which clarified what the default mount option check was for, added info on enabling acl as a default mount option and included beginning info for Mask section.)
Line 20: Line 20:
 
* Current version of file utils (<code>ls</code>, <code>cp</code>, <code>mv</code>, etc) with support for working with ACLs
 
* Current version of file utils (<code>ls</code>, <code>cp</code>, <code>mv</code>, etc) with support for working with ACLs
  
=== Confirm filesystem is mounted with proper support - <code>tune2fs</code> ===
 
  
You can use <code>tune2fs -l /dev/X | grep acl</code> (where X is the device).
+
== Enabling ACL support ==
 
<syntaxhighlight lang="bash">
 
sudo tune2fs -l /dev/sdaX | grep acl
 
</syntaxhighlight>
 
  
<pre>
+
=== Confirm Kernel has support built-in ===
Default mount options:    user_xattr acl
 
</pre>
 
  
If it's not there, it would need to be added as a mount option for any filesystem that supports ACLs.
+
<ref name="debianhelp-ACL-config-in-debian" />
 
 
=== Confirm Kernel has support built-in <ref name="debianhelp-ACL-config-in-debian" /> ===
 
  
 
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.
 
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.
Line 60: Line 51:
 
</pre>
 
</pre>
  
 +
=== Confirm filesystem is mounted with proper support ===
 +
 +
<ref name="archlinux-wiki-acls" />
 +
<ref name="ubuntu-wiki-acls" />
 +
 +
First, you can use <code>tune2fs</code> to check the default mount options for the filesystem in question:
 +
 +
<syntaxhighlight lang="bash">
 +
sudo tune2fs -l /dev/sdaX | grep acl
 +
</syntaxhighlight>
 +
 +
<pre>
 +
Default mount options:    user_xattr acl
 +
</pre>
 +
 +
If it's not there, it would need to be added as a mount option for any filesystem that supports ACLs. Also, you should double-check <code>/proc/mounts</code> to confirm that ACL support hasn't been overridden.
 +
 +
<syntaxhighlight lang="bash">
 +
$ grep noacl /proc/mounts
 +
</syntaxhighlight>
 +
 +
<pre>
 +
</pre>
 +
 +
 +
=== Enable <code>acl</code> mount option ===
 +
 +
<ref name="archlinux-wiki-acls" />
 +
 +
If if it is not already enabled, you can set <code>acl</code> as a default mount option by using the <code>tune2fs -o option partition</code> command:
 +
 +
<syntaxhighlight lang="bash">
 +
sudo tune2fs -o acl /dev/sdXY
 +
</syntaxhighlight>
 +
 +
Using the default mount options instead of an entry in <code>/etc/fstab</code> is very useful for external drives as those partitions will be mounted with the <code>acl</code> option enabled on other Linux machines. In that case there is no need to edit <code>/etc/fstab</code> on every machine.
 +
 +
'''Note''': <code>acl</code> is specified as default mount option when creating an ext2/3/4 filesystem. This is configured in <code>/etc/mke2fs.conf</code>.
  
 
== ACL Types ==
 
== ACL Types ==
Line 150: Line 179:
 
There is a correspondence between the file owner, group, and other permissions and specific ACL entries:  
 
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.  
+
* The owner permissions correspond to the permissions of the ACL_USER_OBJ (owner, <code>user::rwx</code>) 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.  
+
* 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, group::rwx) entry.  
* The other permissions correspond to the permissions of the ACL_OTHER_OBJ (other) entry.
+
* The other permissions correspond to the permissions of the ACL_OTHER_OBJ (other, <code>other::rwx</code>) 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.'''''
 
'''''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.'''''
 +
 +
 +
== Mask ==
 +
 +
<ref name="informit-unix-linux-sysadmin-handbook">
 +
 +
In more complex ACLs, the traditional group permission bits correspond to a special ACL entry called the <code>mask</code> rather than the owning group (group::rwx) ACL entry. The mask limits the access that the ACL can confer upon all named users, all named groups, and the default (aka, "primary") group.
 +
 +
In other words, the mask specifies an upper bound on the access that the ACL can assign to individual groups and users. It is conceptually similar to the umask , except that the ACL mask is always in effect and specifies the allowed permissions rather than the permissions to be denied. ACL entries for named users, named groups, and the default group can include permission bits that are not present in the mask, but the kernel simply ignores them. As a result, the traditional mode bits can never understate the access allowed by the ACL as a whole. Furthermore, clearing a bit from the group portion of the traditional mode clears the corresponding bit in the ACL mask and thereby forbids this permission to everyone but the file's owner and those who fall in the category of "other".
  
 
=== Valid ACLs ===
 
=== Valid ACLs ===
Line 312: Line 350:
  
 
<ref name="informit-unix-linux-sysadmin-handbook">[[informit:9780131480056|UNIX and Linux System Administration Handbook, 4th Edition]]</ref>
 
<ref name="informit-unix-linux-sysadmin-handbook">[[informit:9780131480056|UNIX and Linux System Administration Handbook, 4th Edition]]</ref>
 +
 +
<ref name="archlinux-wiki-acls">[https://wiki.archlinux.org/index.php/ACL Arch Linux Wiki - ACLs]</ref>
 +
 +
<ref name="ubuntu-wiki-acls">[https://help.ubuntu.com/community/FilePermissionsACLs Ubuntu wiki - ACLs]</ref>
  
 
</references>
 
</references>
Line 317: Line 359:
 
=== Queued up ===
 
=== Queued up ===
  
 
 
* https://help.ubuntu.com/community/FilePermissionsACLs
 
 
* http://brunogirin.blogspot.com/2010/03/shared-folders-in-ubuntu-with-setgid.html
 
* http://brunogirin.blogspot.com/2010/03/shared-folders-in-ubuntu-with-setgid.html
 
* http://linuxgazette.net/152/prestia.html
 
* http://linuxgazette.net/152/prestia.html
Line 334: Line 373:
 
* https://publib.boulder.ibm.com/tividd/td/TSMC/GC32-0789-04/en_US/HTML/ans5000090.htm
 
* https://publib.boulder.ibm.com/tividd/td/TSMC/GC32-0789-04/en_US/HTML/ans5000090.htm
 
* http://www.vanemery.com/Linux/ACL/linux-acl.html
 
* http://www.vanemery.com/Linux/ACL/linux-acl.html
 
  
 
* https://docs.google.com/document/d/1-US07DZV7eoam1P8ZrTM7UgZF5DQs0Q8NNBAXVAem_Y/edit
 
* https://docs.google.com/document/d/1-US07DZV7eoam1P8ZrTM7UgZF5DQs0Q8NNBAXVAem_Y/edit

Revision as of 16:36, 2 March 2015


Overview

[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


Enabling ACL support

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)
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

Confirm filesystem is mounted with proper support

[5] [6]

First, you can use tune2fs to check the default mount options for the filesystem in question:

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. Also, you should double-check /proc/mounts to confirm that ACL support hasn't been overridden.

$ grep noacl /proc/mounts


Enable acl mount option

[5]

If if it is not already enabled, you can set acl as a default mount option by using the tune2fs -o option partition command:

sudo tune2fs -o acl /dev/sdXY

Using the default mount options instead of an entry in /etc/fstab is very useful for external drives as those partitions will be mounted with the acl option enabled on other Linux machines. In that case there is no need to edit /etc/fstab on every machine.

Note: acl is specified as default mount option when creating an ext2/3/4 filesystem. This is configured in /etc/mke2fs.conf.

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

[7] [8]

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.


Note:

  • 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

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

[7] [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, user::rwx) 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, group::rwx) entry.
  • The other permissions correspond to the permissions of the ACL_OTHER_OBJ (other, other::rwx) 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.


Mask

Cite error: Closing </ref> missing for <ref> tag

[9]

[7]

[4]

[10]

[2]

[11]

[8]

[3]

[5]

[6]

</references>

Queued up

  • 1.0 1.1 Cite error: Invalid <ref> tag; no text was provided for refs named redhat-v3-acls
  • 2.0 2.1 2.2 2.3 2.4 acl(5) - Linux man page
  • 3.0 3.1 UNIX and Linux System Administration Handbook, 4th Edition
  • 4.0 4.1 ACL(Access Control List) Configuration in Debian
  • 5.0 5.1 5.2 Arch Linux Wiki - ACLs
  • 6.0 6.1 Ubuntu wiki - ACLs
  • 7.0 7.1 7.2 7.3 Documentation > Security Guide > Local Security > Chapter 9. Access Control Lists in Linux
  • 8.0 8.1 The University of Tennessee Knoxville > Resources > IT Support > IT Knowledge Base > Linux/POSIX ACLs
  • Support > Product Documentation > Red Hat Storage > 2.0 > Administration Guide > 9.5.3. Removing POSIX ACLs
  • IBM > Tivoli Software > File system and ACL support
  • setfacl(1) - Linux man page