POSIX Access Control Lists - Revision history

Phil.cs.jhu.edu at 19:19, 12 June 2017

2017-06-12T19:19:41Z

Phil.cs.jhu.edu: /* Summary */ Add a tiny bit about the "POSIX" name.

2016-09-14T14:26:05Z

Summary: Add a tiny bit about the "POSIX" name.

Phil.cs.jhu.edu: Remove redundant paragraph.

2016-09-14T13:51:00Z

Remove redundant paragraph.

Phil.cs.jhu.edu at 20:29, 13 September 2016

2016-09-13T20:29:54Z

Phil.cs.jhu.edu: Created page with "Access Control Lists (ACLs) are a way of modifying file permissions in a way that is far more granular and flexible than Unix File Permission Primer|standard Unix file permi..."

2016-09-13T19:51:51Z

Created page with "Access Control Lists (ACLs) are a way of modifying file permissions in a way that is far more granular and flexible than Unix File Permission Primer|standard Unix file permi..."

New page

Access Control Lists (ACLs) are a way of modifying file permissions in a way that is far more granular and flexible than [[Unix File Permission Primer|standard Unix file permissions]]. Unfortunately, ACLs are also more complex and can lead to very confusing situations if you're not careful. Consequently, we don't recommend using ACLs unless you find yourself in a situation that cannot work with the standard permission model. (When in doubt, you can always email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for help with our systems.)

There are two types of ACLs in use on our systems. This page covers ''POSIX'' ACLs, which are used on our [[Linux Clients on the CS Undergrad Net|undergrad Linux clients]]. For our [[Linux Clients on the CS Grad/Research Net|graduate Linux clients]], please see the page on [[NFSv4 Access Control Lists]].

Our filesystems also support POSIX Access Control Lists (ACLs). We don't recommend using them unless you have a specific reason to do so, because they can easily add a confusing amount of complexity to your file permissions. Still, we're mentioning them, if briefly, for completeness.

== ACL Overview ==

The standard Unix permissions allow you to specify permissions for exactly one account (which is almost always your account), exactly one group, and "everyone else". Sometimes you might want more flexibility than that. You might, for example, want members of one group to be able to change a file, members of another group to be able to read it, and no access for everyone else. The standard Unix file permissions can't do that.

Enter ACLs.

ACLs are things you attach to files and directories that basically just list additional accounts and groups with permissions specific to each account and group. You look at ACLs with the <tt>getfacl</tt> command and set them with the <tt>setfacl</tt> command. If a file or directory has ACLs, it will show a "'''+'''" symbol at the end of the <tt>ls -l</tt> permission listing, like the <tt>README</tt> file here:

<pre>
-rw-r-----+ 1 account users 4153 Apr 16 2013 README
</pre>

ACLs (unlike standard Unix permissions) have only one format, which is used for both setting and displaying them:

''permission-set'':''account-or-group'':''permissions''

"''permission-set''" is one of "user", "group", and "other". (When setting ACLs, you can abbreviate those to "u", "g", and "o".) "''account-or-group''" is the account name for "user" ACLs and the group name for "group" ACLs. If you leave the "''account-or-group''" section empty, you'll affect the equivalent standard Unix permission set. (So <tt>setfacl -m group::rw ''file''</tt> is the same as <tt>chmod g=rw ''file''</tt>.) "''permissions''" is some combination of "r", "w", and "x", for read, write, and execute permissions, or a "-" to signify no permissions. ACLs don't have the extra properties for set UID, set GID, and sticky bit.

== Viewing ACLs ==

The output of <tt>getfacl</tt> will look something like this:

<pre>
# file: README
# owner: account
# group: users
user::rw-
user:bob:r--
group::---
mask::r--
other::---
</pre>

That shows that the "<tt>bob</tt>" account has read access to the file, even though no one (aside from the owner) has any permissions for it. (We'll cover the "mask" line shortly.)

== Setting and Changing ACLs ==

To add an ACL to a file (or to change the permissions on an existing ACL), use <tt>setfacl -m</tt> :

setfacl -m u:bob:rw ''file''

To remove an ACL, use <tt>setfacl -x</tt>, ''without the permission section of the ACL'':

setfacl -x u:bob ''file''

== ACL Masks ==

One nonintuitive thing that comes up with ACLs is the ACL ''mask''. As soon as you add an ACL to a file, you will see a "mask" line show up in the <tt>getfacl</tt> output in addition to the ACL you added. The works a little like the symbolic representation of a umask: it gives the maximum permissions allowed to any account or group with its own ACL. It is also what's shown in the "group" section of the output of <tt>ls -l</tt>.

To repeat that for emphasis: Once you add an ACL to an object, <tt>ls -l</tt> will show ''the ACL mask'' in its middle set of permissions, '''not''' the permissions corresponding to the group that owns the object. The <tt>README</tt> example above shows this: the <tt>users</tt> group has no permissions for the file even though <tt>ls -l</tt> shows "<tt>-rw-r-----+</tt>".

Normally, <tt>setfacl</tt> will set the mask appropriately for the ACLs on the file. In some circumstances, especially if you use <tt>chmod</tt> on a file with ACLs, the mask may get out of sync with the other ACLs, in which case <tt>getfacl</tt> will show things like this:

<pre>
user:bob:rw- #effective:r--
mask::r--
</pre>

That means, roughly, "<tt>bob</tt> has an ACL that should give him read and write permissions, but because of the mask, he'll really only have read permissions."

To reset the mask, you can run:

setfacl --mask -m m::- ''file''

== Default ACLs ==

Finally, directories can have "default ACLs". They have the same format as regular ACLs, but with "default:" at the beginning. (You can shorten that to "d:" if you want.) When a file is created in a directory with default ACLs, it automatically gets ACLs based on the defaults. When a directory is created in a directory with default ACLs, it gets ACLs based on the defaults (just like a file) and also gets its own copies of the default ACLs. Here's an example:

$ '''mkdir example'''
$ '''setfacl -m default:user:bob:rw example'''
$ '''touch example/foo'''
$ '''getfacl -c example/foo'''
user::rw-
user:bob:rw-
group::---
mask::rw-
other::---

== Summary ==

In summary, ACLs are useful, but can be potentially confusing (especially if you set them and then forget about them later). We don't really recommend using them unless you absolutely need to do so.

[[Category:Linux Clients]]

← Older revision		Revision as of 14:26, 14 September 2016
Line 84:		Line 84:

	In summary, ACLs are useful, but can be potentially confusing (especially if you set them and then forget about them later). We don't really recommend using them unless you absolutely need to do so.		In summary, ACLs are useful, but can be potentially confusing (especially if you set them and then forget about them later). We don't really recommend using them unless you absolutely need to do so.
		+
		+	Also, just because this should be mentioned ''somewhere'', but it doesn't really have any bearing on using the ACLs: There's technically no such thing as "POSIX" ACLs. "POSIX" comprises a set of Unix-related standards approved by the IEEE. The IEEE has never actually approved a standard for Access Control Lists. The ACLs described above are based on a proposed, but never approved, IEEE standard. Despite never being formally approved, the proposal has been widely implemented, so it's become a ''de-facto'' standard. No one's come up with a better name for them than "POSIX ACLs", so that's the name everyone uses.

	[[Category:Reference Material]]		[[Category:Reference Material]]

← Older revision		Revision as of 13:51, 14 September 2016
Line 2:		Line 2:

	There are two types of ACLs in use on our systems. This page covers ''POSIX'' ACLs, which are used on our [[Linux Clients on the CS Undergrad Net\|undergrad Linux clients]]. For our [[Linux Clients on the CS Grad/Research Net\|graduate Linux clients]], please see the page on [[NFSv4 Access Control Lists]].		There are two types of ACLs in use on our systems. This page covers ''POSIX'' ACLs, which are used on our [[Linux Clients on the CS Undergrad Net\|undergrad Linux clients]]. For our [[Linux Clients on the CS Grad/Research Net\|graduate Linux clients]], please see the page on [[NFSv4 Access Control Lists]].
−
−	Our filesystems also support POSIX Access Control Lists (ACLs). We don't recommend using them unless you have a specific reason to do so, because they can easily add a confusing amount of complexity to your file permissions. Still, we're mentioning them, if briefly, for completeness.

	== ACL Overview ==		== ACL Overview ==

← Older revision		Revision as of 20:29, 13 September 2016
Line 87:		Line 87:
	In summary, ACLs are useful, but can be potentially confusing (especially if you set them and then forget about them later). We don't really recommend using them unless you absolutely need to do so.		In summary, ACLs are useful, but can be potentially confusing (especially if you set them and then forget about them later). We don't really recommend using them unless you absolutely need to do so.

−	[[Category:~~Linux Clients~~]]	+	[[Category:Reference Material]]

@@ Line 1: / Line 1: @@
 Access Control Lists (ACLs) are a way of modifying file permissions in a way that is far more granular and flexible than [[Unix File Permission Primer|standard Unix file permissions]].  Unfortunately, ACLs are also more complex and can lead to very confusing situations if you're not careful.  Consequently, we don't recommend using ACLs unless you find yourself in a situation that cannot work with the standard permission model.  (When in doubt, you can always email [mailto:support@cs.jhu.edu support@cs.jhu.edu] for help with our systems.)
-There are two types of ACLs in use on our systems.  This page covers ''POSIX'' ACLs, which are used on our [[Linux Clients on the CS Undergrad Net|undergrad Linux clients]].  For our [[Linux Clients on the CS Grad/Research Net|graduate Linux clients]], please see the page on [[NFSv4 Access Control Lists]].
+We used to use POSIX ACLs on our systems, but we now use [[NFSv4 Access Control Lists]] exclusively.  Please read the NFSv4 page for more information.
 == ACL Overview ==