Linux‎ > ‎

ACL on Linux -- POSIX Access control list on linux

Thank you for visiting this page, this page has been update in another link ACL on Linux
Nowadays, people managing large cluster system feel that traditional linux permission model is not enough to meet the different requirement from end users, local ACL on linux is an option for them if they are not going to NFS4.
Here are some examples:

Check activation of acl in kernel

Most of linux kernels now support ACL by default, to check if it's enabled

/boot/config-2.6.18-194.26.1.el5:CONFIG_EXT2_FS_POSIX_ACL=y
/boot/config-2.6.18-194.26.1.el5:CONFIG_EXT3_FS_POSIX_ACL=y
/boot/config-2.6.18-194.26.1.el5:CONFIG_EXT4_FS_POSIX_ACL=y
/boot/config-2.6.18-194.26.1.el5:CONFIG_FS_POSIX_ACL=y
/boot/config-2.6.18-194.26.1.el5:CONFIG_XFS_POSIX_ACL=y
/boot/config-2.6.18-194.26.1.el5:CONFIG_NFS_V3_ACL=y
/boot/config-2.6.18-194.26.1.el5:CONFIG_NFSD_V3_ACL=y
/boot/config-2.6.18-194.26.1.el5:CONFIG_NFS_ACL_SUPPORT=m

Or, use tune2fs to check a particular fs, not for xfs of course

# tune2fs -l /dev/sda9

tune2fs 1.39 (29-May-2006)

Filesystem volume name:   /home

...

Default mount options:    user_xattr acl

...

Setup test environment

I created two groups test1 and test2, user john and Tim, created dir is on a xfs filesystem
# groupadd test1
# groupadd test2
# useradd -g test1 john
# useradd -g test2 Tim
# mkdir acltest
# chown john:test1 acltest

Check ACL
$ getfacl acltest
# file: acltest
# owner: john
# group: test1
user::rwx
group::r-x
mask::rwx
other::r-x

Test1, primary owner test

setfacl -m Tim:rwx acltest
$ getfacl acltest
# file: acltest
# owner: john
# group: test1
user::rwx
user:Tim:rwx
group::r-x
mask::rwx
other::r-x

Test2, both users create subdirectories under acltest

acltest]$ getfacl johntest
# file: johntest
# owner: john
# group: test1
user::rwx
group::r-x
other::r-x

acltest]$ getfacl timtest
# file: timtest
# owner: Tim
# group: test2
user::rwx
group::r-x
other::r-x

Test3, can john write files to Tim's subdirectory?

$ id
uid=18945(Tim) gid=3374(test2) groups=3374(test2)
[acltest]$ touch ./johntest/test
touch: cannot touch `./johntest/test': Permission denied

Test4, default ACL setting -- inheritance options

$ setfacl -d -m Tim:rwx acltest
$ getfacl acltest
# file: acltest
# owner: john
# group: test1
user::rwx
user:Tim:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:Tim:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

Note: default part describe the ACLs that will be inherited by files/directories created under dir acltest

Test5, can john write files to Tim's subdirectory?

tim creates another subdirectory timtest2
$ mkdir timtest2
[Tim@ acltest]$ getfacl timtest2
# file: timtest2
# owner: Tim
# group: test2
user::rwx
user:Tim:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:Tim:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

[john@ acltest]$ touch ./timtest2/test
touch: cannot touch `./timtest2/test': Permission denied
But, Tim can write file into john's
$ getfacl johntest2
# file: johntest2
# owner: john
# group: test1
user::rwx
user:Tim:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:Tim:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

$ touch ./johntest2/test
[Tim@ acltest]$ echo $?
0

Test6, set both Tim and john rwx in ACL extension

In both Tim and john sessions, runn the following commands
$ setfacl -d -m Tim:rwx  -R acltest
$ setfacl -d -m john:rwx  -R acltest

  -R is to apply operations to all files and directories recursively

$ getfacl acltest
# file: acltest
# owner: john
# group: test1
user::rwx
user:Tim:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:john:rwx
default:user:Tim:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

Test7, both users now can write file into other's subdirectories.

Now, both users can access each other's new subdirectories.
$ touch ./johntest3/test
[Tim@acltest]$ getfacl ./johntest3
# file: johntest3
# owner: john
# group: test1
user::rwx
user:john:rwx
user:Tim:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:john:rwx
default:user:Tim:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

Test8, how about old subdirectories after -R option applied ?

$ getfacl ./johntest
# file: johntest
# owner: john
# group: test1
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:john:rwx
default:user:Tim:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

[Tim@ acltest]$ touch ./johntest/test
touch: cannot touch `./johntest/test': Permission denied

Clearly, user Tim is in the default extension attribute with rwx permission, but has no access to johntest directory. Compare with subdirectory johntest3, there is no user Tim in user attribute, so probably that's why.
To set all old subdirectories all writable for both john and Tim, run
$ setfacl -m john:rwx -R acltest
$ setfacl -m Tim:rwx -R acltest

 In principle, it should work according to http://users.suse.com/~agruen/acl/linux-acls/online/

It's true, Linux POSIX ACL behaves varies in different kernel.  And the best linux ACL description from the link above is for SUSE.  Also, during my test, I noticed that on SL6, kernel 2.6.32-358.18.1.el6.x86_64, acl setting test on xfs 3.1.1 can make kernel crash. In my this article test, it was on kernel RHEL 2.6.18-194, xfs 2.9.4.
You should do a full test before start to use it in production.

Access Check Algorithm

A process requests access to a file system object. Two steps are performed. Step one 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.

A process can be a member in more than one group, so more than one group entry can match. If any of these matching group entries contain the requested permissions, one that contains the requested permissions is picked (the result is the same no matter which entry is picked). If none of the matching group entries contains the requested permissions, access will be denied no matter which entry is picked.

The access check algorithm can be described in pseudo-code as follows.

If
the user ID of the process is the owner, the owner entry determines access

else if
the user ID of the process matches the qualifier in one of the named user entries, this entry determines access

else if
one of the group IDs of the process matches the owning group and the owning group entry contains the requested permissions, this entry determines access

else if
one of the group IDs of the process matches the qualifier of one of the named group entries and this entry contains the requested permissions, this entry determines access

else if
one of the group IDs of the process matches the owning group or any of the named group entries, but neither the owning group entry nor any of the matching named group entries contains the requested permissions, this determines that access is denied

else
the other entry determines access.

If
the matching entry resulting from this selection is the owner or other entry and it contains the requested permissions, access is granted

else if
the matching entry is a named user, owning group, or named group entry and this entry contains the requested permissions and the mask entry also contains the requested permissions (or there is no mask entry), access is granted

else
access is denied.






Comments