Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Unix Access Control Lists (ACL)

For an intro see Slightly Skeptical view on Unix Access Control Lists

News

Re Linux ACLs

From:	John Valdes
Subject:	Re: Linux ACLs
Date:	Tue, 26 Oct 2004 22:34:59 -0500
User-agent:	Mutt/1.2.5i

---

On Tue, Oct 26, 2004 at 09:22:51PM +0200, address@bogus.example.com wrote:
> 
> On 26 Oct, Philippe wrote:
> > 
> >> Are you looking at the POSIX 1003.1e ACLs in the ext2/3 filesystem or SE
> >> Linux stuff?
> > 
> > I thought the Linux ACL followed the Posix recommendations. This was 
> > discussed a couple of weeks ago with Mark. I think Mark has considered 
> > looking the Linux ACL API seriously.
> 
> I searched high and low for the POSIX API and it still does not make
> sense to me. There is no real documentation and the little I have
> found does not agree with what I find on my own systems, so I
> don't know what to do yet.

I've only taken a cursory look at Linux ACLs (and ACLs in general), so
the following may not be totally correct.  Solaris's & Linux's ACL
implementations have similar command interfaces (eg, "getfacl" and
"setfacl" commands w/ similar syntax & output), and for the most part
follow the POSIX 1003.2c ACL recommendations, but the ACL APIs used
are quite different.  Linux's seems to be modeled after that last (and
withdrawn) draft (17) of the POSIX 1003.1e recommendation.  From what
I've read, Solaris's API is based on an earlier and apparently much
simpler API.  

The primary repository of info on Linux's implementation of ACLs is
<http://acl.bestbits.at/>.  There are copies of all the relevant
manpages there (commands, system calls, and library functions), plus a
link to a paper presented at USENIX 2003 which talks about the state
of POSIX ACLs on Linux (<http://www.suse.de/~agruen/acl/linux-acls/>)
as of the time of writing.  There are also links to the POSIX draft
documents, FWTW.  The ACL patches and information presented on this
site are what were implemented in the 2.6 linux kernel (and in
SELinux), so regardless of what becomes of the POSIX ACL "standard",
it seems that this will be/is the Linux ACL standard (at least for
now; we are talking about Linux afterall ;) ).  Note that besides the
2.6 kernel, I believe RedHat >= 8.0 as well as newer versions of SuSE
at a minimum included ACL support in their shipping 2.4.x kernels.

BTW, the FreeBSD ACL API appears to be similar to the Linux API, and
I'm guessing that the Mac OS X API if/when that comes will follow the
FreeBSD one, so it looks like there'll be no avoiding the more
complicated API if one wants cross-platform ACL support in
cfengine... ;)

John

a-sct-attributes

Date:	Tue, 24 Oct 2000 12:21:04 +0100
From:	"Stephen C. Tweedie" <sct@redhat.com>
To:	Andreas Gruenbacher <ag@bestbits.at>
Subject: Re: [PROPOSAL] Extended attributes for Posix security extensions

Hi,

On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote:
> 
> This is a proposal to add extended attributes to the Linux kernel.
> Extended attributes are name/value pairs associated with inodes.

What timing --- we had a long discussion (actually, several!) about
this very topic at the Miami storage workshop last week.

One of the main goals we had in getting people together to talk about
extended attributes in general, and ACLs in particular, was to deal
with the API issues cleanly.  In particular, we really want the API to
be at the same time:

   * General enough to deal with all of the existing,
     mutually-incompatible semantics for ACLs and attributes; and

   * Specific enough to define the requested semantics unambiguously
     for any one given implementation of the underlying attributes.

These points are really important.  We have people wanting to add ACL
support to ext2 in a manner which Samba can use --- can we do POSIX
ACLs with NT SID identifiers rather than with unix user ids?  If we
mount an NTFS filesystem, it will have native ACLs on disk.  How does
the API speficy that we want NT semantics, not POSIX semantics, for a
given request?

There is also the naming issue.  There are multiple independent
namespaces.  For extended attributes, there may be totally separate
namespaces for user attributes and for system ones, or there may be a
common namespace with per-attribute system status.  Again, these
different sets of semantics _already exist_ on filesystems which Linux
can mount (eg. NTFS, JFS and XFS), so the API has to deal with them.

There is already a kernel API which has this flexibility: the BSD
socket API handles these issues through the concepts of protocol
families and address families.  Those same two concepts are perfectly
matched to the extended attributes problem.


The proposal defines two "families" of attribute entities: attribute
families and name families.

An attribute family might be ATR_USER or ATR_SYSTEM to specify that we
are dealing with arbitrary user or system named extended attributes,
or ATR_POSIXACL to specify POSIX-semantics ACLs.  Obviously, this can
be extended to other ACL semantics without revving the API --- a new
attribute family would be all that is needed.

The "name family" is the other part of the equation.  Attributes in
the ATR_USER or ATR_SYSTEM families might be named with counted
strings, so they would have names in the ANAME_STRING name family.
POSIX ACLs, however, have a different namespace: ANAME_UID or
ANAME_GID.  The API cleanly deals with the difference between user and
group ACLs.  It also makes it easy to add support later on for more
complex operations: if we want to add NT SID support to ext2 ACLs so
that Samba and local accesses get the same access control, we can pass
ANAME_NTSID names to the ATR_POSIXACL attribute family without
changing the API.

Obviously the combinations of name types supported for any given
attribute family will depend on the underlying implementation, but
that's the whole point --- the API is expressive enough to define
unambiguously what the application is trying to do, so that if the
underlying filesystem doesn't support (say) POSIX ACLs, we get an
error back telling us so rather than attempting to do an incomplete
map of the POSIX request onto whatever the underlying filesystem
happens to support.


Before we look at the syscall API in detail, there's one other point
to note.  It is common to want to read or set one individual attribute
in isolation (even if it is an atomic set-and-get which is being
performed on that attribute).  Sometimes, however, you want to access
the entire set of related attributes as an ordered list.  ACLs are the
obvious case: if you have underlying semantics which allow you to mix
both PASS and DENY ACLs on a file, then the order of the ACLs
obviously matters.  

In such cases, you may sometimes want just to query or set the ACL for
a specific user, but often you will want to do something more complex
such as change the order of ACLs on the list or replace the entire
list as a single entity --- and you want to do so atomically.  So, the
simple "SET" and "GET" operations on named attributes (which
correspond to writing and reading the ACLs for specific named users in
the ATR_POSIXACL family) need to be augmented with SET variants which
append or prepend to the ACL list, or which atomically replace the old
ACL list in its entirety.


Our proposed kernel API looks something like this:

	sys_setattr (char *filename, int attrib_family, int op, 
		     struct attrib *old_attribs, int *old_lenp,
		     struct attrib *new_attribs, int new_len);

	sys_fsetattr(int fd, int attrib_family, int op, 
		     struct attrib *old_attribs, int *old_lenp,
		     struct attrib *new_attribs, int new_len);

where <op> can be

	ATR_SET		overwrite existing attribute
	ATR_GET		read existing attribute
	ATR_GETALL	read entire ordered attribute list (ignores new val)
	ATR_PREPEND	add new attribute to start of ordered list
	ATR_APPEND	add new attribute to end of ordered list
	ATR_REPLACE	replace entire ordered attribute list

and where <attribs> is a buffer of length <len> bytes of variable
length struct attrib records:

struct attrib {
	int	rec_len;		/* Length of the whole record:
					   should be padded to long
					   alignment */
	int	name_family;		/* Which namespace is the name in? */
	int	name_len;
	int	val_len;
	char	name[variable];		/* byte-aligned */
	char	val[variable];		/* byte-aligned */
};

ATR_SET will overwrite an existing attribute, or if the attribute does
not already exist, will append the new attribute (ie. it does not
override existing ACL controls, in keeping with the Principle of Least
Surprise).  If multiple instances of the name already exist, then the
first one is replaced and subsequent ones deleted.  If supplied with
an "old" buffer, all old attributes of that name will be returned.

For the PREPEND/APPEND/REPLACE operations, the entire old attribute
set is returned.

For GET, the <new> specification is read and all attributes which
match any items in <new> are returned, in the order in which they are
specified in <new>.  The actual value in <new> is ignored; only the
name is used.

For GETALL, <new> is ignored entirely.

*old_lenp should contain the size of the old attributes buffer on
entry.  It will contain the number of valid bytes in the old buffer on
exit.  If the buffer is not sufficiently large to contain all of the
attributes, E2BIG is returned.


This is just a first stab at documenting what feels like an
appropriate API.  It should be extensible enough for the future, but
is pretty easy to code to already --- existing filesystems don't have
to deal with any complexity they don't want to. 

Additionally, the use of well-defined namespaces for attributes means
that in the future we can implement things like common code for
generic attribute caching, or process authentication groups for
non-Unix-ID authentication tokens, without having to duplicate all of
that work in each individual filesystem.


The extended attribute patch currently on the acl-devel group simply
doesn't give us the ability to do extended attributes on any
filesystem other than ext2, because it has such specific semantics.
I'd rather avoid that, and I'd rather do so without adding a profusion
of different ACL and attribute syscalls in the process.

Cheers,
 Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org

Recommended Links

• Access Control Lists
• Digital Unix Security Manual -- Product Version:Digital UNIX Version 4.0 or higher March 1996
• SlashdotSGI open-sourcing XFS -- contains a very good discussion of ACLs
• Extended attributes and ACLs for Linux
• Solaris Advanced System Administrator's Guide, Second EditionUnderstanding System Security
• Module Documentation - SolarisACL 0.06 -- Perl module for Access of Solaris ACLs
• Extended attributes and ACLs for Linux

Recommended Papers

***** POSIX Access Control Lists on Linux by Andreas Grünbacher

Traditionally, systems that support the POSIX (Portable Operating System Interface) family of standards [11,2] share a simple yet powerful file system permission model: Every file system object is associated with three sets of permissions that define access for the owner, the owning group, and for others. Each set may contain Read (r), Write (w), and Execute (x) permissions. This scheme is implemented using only nine bits for each object. In addition to these nine bits, the Set User Id, Set Group Id, and Sticky bits are used for a number of special cases. Many introductory and advanced texts on the UNIX operating system describe this model [19].

Although the traditional model is extremely simple, it is sufficient for implementing the permission scenarios that usually occur on UNIX systems. System administrators have also found several workarounds for the model's limitations. Some of these workarounds require nonobvious group setups that may not reflect organizational structures. Only the root user can create groups or change group membership. Set-user-ID root utilities may allow ordinary users to perform some administrative tasks, but bugs in such utilities can easily lead to compromised systems. Some applications like FTP daemons implement their own extensions to the file system permission model [15]. The price of playing tricks with permissions is an increase in complexity of the system configuration. Understanding and maintaining the integrity of systems becomes more difficult.

Engineers have long recognized the deficiencies of the traditional permission model and have started to think about alternatives. This has eventually resulted in a number of Access Control List (ACL) implementations on UNIX, which are only compatible among each other to a limited degree.

This paper gives an overview of the most successful ACL scheme for UNIX-like systems that has resulted from the POSIX 1003.1e/1003.2c working group.

After briefly describing the concepts, some examples of how these are used are given for better understanding. Following that, the paper discusses Extended Attributes, the abstraction layer upon which ACLs are based on Linux. The rest of the paper deals with implementation, performance, interoperability, application support, and system maintenance aspects of ACLs.

The author was involved in the design and implementation of extended attributes and ACLs on Linux, which covered the user space tools and the kernel implementation for Ext2 and Ext3, Linux's most prominent file systems. Parts of the design of the system call interface are attributed to Silicon Graphics's Linux XFS project, particularly to Nathan Scott.

ACLs Support in Linux

O'Reilly Network FreeBSD Access Control Lists

22C116, Notes, Feb. 27, 1995

Under the classic MULTICS system, which was also used by the PRIMOS operating system, each file has an ACL, with access such as the following:

• Read
• Write
• Traverse -- for directories
• Execute -- for data
• EditACL

The read and write rights should be obvious.

The traverse right is used in the context of hierarchical directory structures. A user who has no right to read or write a directory can mention that directory in the path name of a file as long as the user has traverse rights to that directory -- the user is just passing through, but may not open the directory to list its contents.

The right to edit an access control list illustrates one approach to allowing the contents of the access control matrix to be modified. In a sense, all users with the right to edit the access control list of an object can be thought of as co-owners of the object. If one user (the legitimate owner of an object) grants the right to edit that object's ACL to another user, it is like granting the other user a power of attourny over the object.

 

Example: the UNIX file system

Under UNIX, each file has an ACL, but the ACL is strictly limited in structure. Each UNIX ACL has 3 fixed entries:

• An entry for the owner of the file
• An entry for others in the same group as the the owner
• An entry for the general public

The rights associated with each entry are:

• Read
• Write
• Execute/Traverse

The MULTICS project originated as a joint project between MIT, GE and Bell Labs in the mid 1960's. In the late 1960's, Bell pulled out of the MULTICS project, largely because the technical staff of the computing group had concluded that MULTICS was getting too complicated. UNIX was born from this frustration, and the name UNIX is a pun on MULTICS -- suggesting a scaled down system designed to meet a scaled down set of goals.

The simple to implement ACL scheme of UNIX is an example of this. Unlike the MULTICS ACL, it is not general, but it meets the needs of most users of small computer systems. As a result, every UNIX ACL fits exactly in 9 bits of the I-node of the file it describes!

MULTICS was intended to meet the needs of a general information utility, and as such, it had to deal with the problems of large numbers of users, including users from competing organizations. The generality of the MULTICS access control list is well justified by this environment, and the success of PRIMOS in meeting the needs of compaines like Compuserve or The Source (modern examples of computer utilities) amply illustrates the appropriateness of the MULTICS design.

When UNIX systems are extended beyond single departments, the short ACL of UNIX becomes a problem. Distributed versions of UNIX such as the Appolo Domain operating system have been forced to add general ACL's back onto the UNIX file model in order to meet the demands of the large user base that such a system can serve.

Samba-3 Windows file and directory ACLs

Security The Digital UNIX ACLs are based on the POSIX P1003.6 Draft 13 standard. ...

Using ACLs (Access Control Lists)

One of the features of Solaris 2.5 (the new OS that was recently installed on CNS Unix computers) is file ACLs (Access Control Lists). These allow you to have much finer control over access to your files and directories.

In the past, you could give read, write and execute access only to yourself (user), your group (group) and everyone else in the world (other). Now, besides those, you can give access to any individual users that you choose.

Let's say you have a group of people, yourself (sheridan), ivanova and kosh, working on a class project and a file named star_fury you all need to access.

 

Use the setfacl command (set file acl) to set ACLs for that file:

setfacl -s u::rwx,g::---,o::---,m:rwx,u:ivanova:rwx,u:kosh:rwx star_fury

The first user, group and other (where those names are followed by double colons) refer to the standard Unix file permissions. Mask works like the standard Unix umask. The rest of the command adds access for your group.

You can use the keywords user, group, other and mask or the first letter of those words and permissions can be specified in symbolic (rwx) or octal (7=rwx, 6=rw-, etc.) mode, so the following are all equivalent:

setfacl -s u::rwx,g::rw-,o::r-- star_fury
setfacl -s u::7,g::6,o::4 star_fury
setfacl -s user::rwx,group::rw-,other::r-- star_fury
setfacl -s user::7,group::6,other::4 star_fury

To see which ACLs are set, use the getfacl (get file acl) command:

getfacl star_fury

# file: star_fury
# owner: sheridan
# group: other
user::rwx
user:ivanova:rwx        #effective:rwx
user:kosh:rwx           #effective:rwx
group::---              #effective:---
mask:rwx
other:--- 

You can also set default ACLs for directories, which will allow ACLs to be automatically set for any files that are created in those directories. To do this, make the directory:

mkdir bab5

and then set the ACL for the standard Unix groups (user, group, other) and mask and then the defaults for those same groups (using the keyword default or d):

setfacl -s u::7,g::6,m:4,o::6,d:u::7,d:g::5,d:m:7,d:o::5 bab5

Then you can set the defaults for your group (be sure to use the -m option to modify the defaults since the -s option deletes any existing ACLs before it sets a new ACL!):

setfacl -m d:u:ivanova:rwx,d:u:kosh:rwx bab5

and then to see what you've done:

getfacl bab5

# file: bab5
# owner:sheridan 
# group: 1012
user::rwx
group::rw-              #effective:r--
mask:r--
other::rw-
default:user::rwx
default:user:ivanova:rwx
default:user:kosh:rwx
default:group::r-x
default:mask:rwx
default:other::r-x 

and any files created in the bab5 directory will have read write and access permissions for yourself, ivanova and kosh.

For more information, see man setfacl, man getfacl or look at an online description in Sun World Online at

http://www.sun.com:80/sunworldonline/swol-08-1996/swol-08-security.html 

Tutorials

HOWTO Use filesystem ACLs - Gentoo Linux Wiki

Last modified: July 01, 2008