5.1-R acl problem (again)

[Robert Watson]

On Sun, 10 Aug 2003, Branko F. Gracnar wrote:

> Thanks for quick and very informative answer. 
> 
> You're right about getfacl -d (i used linux + acl patch before, where
> default acls are displayed without any arguments and i didn't read
> getfacl man page). 

Yeah -- the Linux tool implementation is based more on Solaris than on
POSIX.1e.  That has some upsides, and some downsides.  I believe there's
an environmental variable you can set on Linux to cause the
getfacl/setfacl to behave in strict accordance with the spec
("POSIXLY_CORRECT" or the like). 

> Thanks alot again.

Sure.

> But there is one thing, i don't understand. 
> 
> if i issue the following command:
> 
> setfacl -dm u::rwx,g::rx,o::---,u:branko:rwx,m::rwx  directory
> 
> and then create file under that directory, why getfacl reports:
> 
> #file:a/c
> #owner:0
> #group:0
> user::rw-
> user:branko:rwx         # effective: r--
> group::r-x              # effective: r--
> mask::r--
> other::r--
> 
> why is mask just 'r' ?!

One of the contentious issues in the design of POSIX.1e was how to set the
protections on a new object.  There are three variables of interest: the
creation mode requested by a process, the umask of that process, and the
default ACL on the parent directory where the object is being created.  In
5.0-R and 5.1-R, we combine them as follows: we mask all elements of the
creation mode using the umask; we then combine the ACL and combined mode
by converting the default ACL to the access ACL on the new object and
overwriting the access ACL fields with the equivilent fields in the mode.
So in the above example, a mask of r-- is likely a result of the creation
mode and umask having a group mode of 4.

In 5.1-CURRENT, we recently switched these semantics to perform a further
intersection of rights in the ACL, rather than a replacement of rights. 
The result is that if the mask in your default ACL is --- and the
combination of creation mode and umask is r--, you get a mask of --- in
the final access ACL.  This implements the algorithm in the POSIX.1e spec
to the letter: at some point, these semantics got changed during a
retrofit of the ACL code, and it wasn't picked up (this might actually
have been after 5.0 but I haven't checked the logs).

I'm currently in the throes of implementing a mode of operation which uses
the Solaris/Linux algorithm, which works in the following manner: if an
default ACL is being used to create a new object, the default ACL replaces
the umask, rather than combining with it.  This allows directory default
ACLs to override the umask locally, producing more liberal rights, which
may be what you're expecting.  This is a violation of the spec, but it's a
common violation due to its utility (POSIX.1e doesn't allow the "create
more liberal protections" because it was deemed unsafe).  I hope to finish
prototyping this and get a patch out to the current@ list in the next
couple of weeks.  The complication is that currently, the umask and
requested creation mode are combined at the system call layer, above VFS,
so we need to expose them separately on the entry to the file system.  The
result is that all file systems would now have to combine the two
elements, and it touches a lot of code. 

Hope this information is useful, and gives you a good picture of where
we're going. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories