Friday, May 11, 2012

Linux ACLs vs Solaris ACLs

 Today I studied the difference between Access Control List implementation in Linux and Solaris. Generally the latest specification of ACL is contained in the long suffered POSIX 1003.1e. The man page for acl is dated by 2002. Not so fresh indeed! To preserve a compatibility with traditional rwx approach, an IEEE crowd jumped over it's head and invented something unusable. Linux community implemented that in even more unusable manner.

 Let's look at this crap. Here is [Linux] manual cite:

An ACL entry contains an entry tag type, an optional entry tag qualifier, and a set of permissions. ... The qualifier denotes the identifier of a user or a group, for entries with tag types of ACL_USER or ACL_GROUP, respectively. Entries with tag types other than ACL_USER or ACL_GROUP have no defined qualifiers.


 This qualifier-with-no-identifier thing means that you write u:jack or g:staff to denote user jack and group staff. It's intuitive.

 Then we have an obscure permission inheritance behavior. Look at "OBJECT CREATION AND DEFAULT ACLs" section of acl manual:


1. The new object inherits the default ACL of the containing directory as its access ACL.

Ok, that is fine.


2. The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter.

Huh?! Thus only specified permissions remains or what?

Other parts of Linux ACL manual made me crazy too. Correspondence between traditional model and new is non-linear, has conditions and behavior modifiers. It depends on Effective User ID, special ACL mask or presence of other bits. In addition this permissions are managed with special utilities setfacl and getfactl. Standard chmod, ls and other tools are not aware of ACLs!

Now let's look at the Solaris variant. Refer to "Solaris ZFS Administration Guide". The give up with 10 year old standard and armed Solaris with NFSv4 ACL model, which is closer to the NT-style ACLs. This eventually makes me think, that Microsoft engineers invented something that is still lacking in UNIX.


# chmod A+user:gozer:read_data/execute:allow test.dir
# ls -dv test.dir
drwxr-xr-x+  2 root     root           2 Aug 31 12:02 test.dir
     0:user:gozer:list_directory/read_data/execute:allow
     1:owner@::deny
     2:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/write_xattr/execute/write_attributes/write_acl
         /write_owner:allow
     3:group@:add_file/write_data/add_subdirectory/append_data:deny
     4:group@:list_directory/read_data/execute:allow
     5:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
         /write_attributes/write_acl/write_owner:deny
     6:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow





Just use ls -v and you already know, who may what. For ACL managment just use chmod and other tools with additional parameters.

Why there is no NFSv4 ACLs on Linux? I found that SGI made patches in 2008. See excellent presentation
Unfortunately SGI died.