Extended ACLS

(Note: Most of this material comes from a paper by Andreas Grünbacher of SuSE Labs. See http://www.suse.de/~agruen/acl/linux-acls/online/. It was presented (at least) at the 2003 USENIX Annual Technical Conference.

What are Extended ACLS? ACLs equivalent with the file mode permission bits are called minimal ACLs. They have three ACL entries. ACLs with more than the three entries are called extended ACLs.

What do they do for us? An example may help.

Business situation:

• A project has been set up to update employee policies, benefits, etc.

• The "project deliverable" is a new employee manual.

• Various groups (legal, HR, management) need access to the proposed manual.

• In order to manage changes only an “Editors” group will have write access to the proposed manual itself.

• All other participants will have Read-Only access to the manual.

• All project participants need an area where they can post comments.

• Access to the proposed manual must be restricted from all others (except root).

A possible technical solution using the traditional methods

• Create two groups

  "Project" - all project participants

  "Editors" - those modifying the manual

• Create the following directory structure for the project

/Project	root	Project	Other
	r w x	r - x	- - -
/Project/Comments	root	Project	Other
	r w x	r w x	- - -
/Project/Manual	root	Editors	Other
	r w x	r w x	r - x

This solution, though reasonable, requires an extra group. More complex situations could get unwieldy. Another possibility would be to use hard links but this adds it's own set of issues.

Extended ACLs solution

• Create two directories, /Comments and /Manual (user and group: root)

• Grant the following groups rwx to /Comments: Editors, HR, Legal, Management

• Grant the following permissions to /Manual:

Editors r w x; HR, Legal and management r - x

The added functionality of Extended ACLs allows multiple users and/or groups to be assigned differing permissions to the same file or directory and eliminates the need for creating additional groups and, in a situation like this, having to keep the 'project' group in sync when there are changes to HR, Legal or Management.

Requirements for Extended ACLs

• Extended attributes (note this is different than extended ACLs) because Extended ACLs is implemented by using extended attributes. Ext2, ext3, IBM JFS, ReiserFS and SGI XFS are known to support extended attributes.

• Kernel 2.5.46 or above unless you use a SuSE/United Linux Consortium distribution where they were implemented it in the 2.4 kernel.

• Acls activated on the file system via one of the following:

  • mount -t reiserfs -o rw,remount,acl /dev/<device> <mountpoint>

  • adding acl to the options in fstab

Implementing Extended ACLs

• Determine if they are used on your file system: Attempt to set an extended ACL with 'setfacl -m g:<group name>:<permissions>'. If 'Operation not supported' is returned then the feature has not been activated. A telltale sign that they are implemented is if the 'ls' command appends a plus sign to a permissions list on a file or directory. This is very important because, with extended ACLS applied, the group component of the permissions list (permissions of the owning group) will no longer reflect the whole permission 'picture'.

• Implementing them if they aren't already: Use one of the options listed in the last 'requirement' from above.

• Managing them once they are implemented: Use getfacl to view and setfacl to define.

  • Characteristics of getfacl:

    • Shows each ACL

    • Adds a note if the ACL is limited by the mask

    • Lists/notes the default ACL last if it exists (a default ACL only applies to directories and is inherited by objects created within the directory afterwards).

  • Characteristics of setfacl:

    • A mask is automatically created if needed but not explicitly provided.

  • Common setfacl formats (underscores represent permissions):

    • setfacl -m [u | g]:[name | uid]:_ _ _ <directory>

      • Example: setfacl -m g:users:rwx /UserData (Add rwx for group 'users')

    • setfacl -d -m [u | g]:[name | uid]:_ _ _ <directory>

      • Example: setfacl -d -m u:root:rwx /PrivateArea (Add default ofrwx for user 'root')

    • setfacl -m m:_ _ _ <directory>

      • Example: setfacl -m m:rwx /GroupData (restore full mask if chmod reduced it)

Issues with Extended ACLs

• The ext2 and ext3 file systems limit extended attributes to one block (default 1024 bytes for Red Hat). ReiserFS has a 64K limit. A statement in the paper said that the latter limit allowed for 8191 ACLS which implies that each extended ACL uses 8 bytes. If this is correct then the ext2 and ext3 file systems could hold 128 ACLs for a file or directory which should be more than adequate.

• Since Linux does ACL caching for performance reasons, extended ACLs will consume additional RAM.

• Determining effective permissions when multiple possibilities apply. Once multiple permissions are allowed on a file or directory a user or process can have differing permissions to it: one based on the user ID and possibly multiple others based on the groups to which the user ID belongs. For Linux this is resolved in a two-step process. The first step “selects the ACL entry that most closely matches the requesting process. The ACL entries are looked at in the following order: owner, named users, (owning or named) groups, others. Only a single entry determines access. Step two checks if the matching entry contains sufficient permissions ... If any .. matching group entr[y] contain[s] the requested permissions, one that contains the requested permissions is picked ... If none of the matching group entries contains the requested permissions, access will be denied no matter which entry is picked. “ (quoted from the paper). The paper has a rather long list of 'If ... Else If... Else If's defining the two-step process.

• Backward compatibility: Implemented as follows

  • All of the extended permissions are associated with the 'group' class which includes the traditional owning group. In this case the definition of 'group class' is redefined to mean “the upper bound of permissions assigned by any individual extended ACL entry”.

  • There is a mask entry which is included with extended ACLs and enforces the 'upper bound' mentioned above. What happens is that, if a non-extended-ACL program (chmod, the GUI interfaces, other programs which may re-write files) is later used to set ACLs on a file system entry to 'less than' the extended ACL permissions, the mask will be set to reflect this. The extended ACL mechanism is designed to look at this mask and insure that any extended ACL permissions which exceed it's bounds are made ineffective. The 'bad news' is that chmod and programs like it can foul up the extended ACL scheme. The 'good news' is that, because the mask is a separate entry from the individual extended ACLs, a record of the extended ACL entries is retained. It can be used figure out what happened and decide what to in the situation.

  • Other issues to consider: Moving files/directories from Extended-ACL-enabled file systems to those where it is not enabled, “surprising” behavior due to differences in the way Samba and NFS implement permissions (if the file system is shared in these ways), differences in the ways Extended ACLs are implemented on various *NIX systems

• Backup of extended ACL information: 'Tar' and 'cpio' are not capable of doing this. A 'star' utility (get it from ftp.berlios.de/pub/star) can back them up. A less desirable way (but nonetheless possible) would be to output the results of getfacl to a file, back this file up and use it with setfacl to restore extended ACLs.

Suggestions

• Assign extended ACLs to directories rather than files, set a default ACL.

• Rename chmod, etc. to prevent accidental use. Possibly replace them with a script stating “This system uses extended ACLS, use getfacl and setfacl instead of this utility”.