Re: 5.1-R acl problem (again)

On Sat, 9 Aug 2003, [iso-8859-2] Branko F. Graènar wrote:

> Now i create directory /export/a. I want to be owned by root:wheel,
> others will no have any access at all and i want that user branko will
> have rw access to it. 
> 
> # mkdir a
> 
> # getfacl a
> #file:a
> #owner:0
> #group:0
> user::rwx
> group::r-x
> other::r-x
> 
> # setfacl -m u::rwx,g::rx,o::---,u:branko:rwx a
> 
> # getfacl a
> #file:a
> #owner:0
> #group:0
> user::rwx
> user:branko:rwx
> group::r-x
> mask::rwx
> other::---
> 
> (testing as branko - works okay)
> 
> Now, if root creates some files (od dirs) in 'a', owner of that file
> will be root and only standard unix triple acl will be assigned, so that
> user branko will not be able to access that file read/write.
> 
> Well, it seems, that default directory acl need to be set to achive
> above goal. 
> 
> # setfacl -b a

This strips your extended access ACL from a, so it now just has owner,
group, and other fields; however, there appears to be an inconsistency in
the POSIX.2c spec regarding using -b without -n -- to make all the entries
disappear and not recalculate a mask, you need "-bn".  We might want to
change this beahvior.

> # setfacl -dm u::rwx,g::rwx,o::--,u:branko:rwx a

A default ACL should now be set, and will be visible if you use "getfacl
-d a".

> # getfacl a
> #file:a
> #owner:0
> #group:0
> user::rwx
> group::r-x
> mask::r-x
> other::---
> 
> WHOOPS, where is user branko?! Why group's acls was not altered from
> 'r-x' to 'rwx' ?! 

Do you mean to use "getfacl -d" here?  This looks like the correct access
ACL.  Try touch a/b, then getfacl a/b, and you'll see the ACL derived from
the default ACL.

> Ofcourse, trying to access directory 'a' as branko doesn't succeed.

The commands you used denied access to user branko.  In POSIX.1e, there
are two kinds of ACLs: access, and default.  Access ACLs are used for
access control, and default ACLs are used to determine the default and
access ACLs of new objects created in a directory.  So if you create a/b,
b will have the access ACL derived from the default ACL on a.

Note that in 5.1-CURRENT, we've changed the semantics for merging the
umask, creation mode, and default ACL, and will probably tweak them a bit
more, but you should be able to see fairly reasonable default ACL behavior
in 5.1 -- certainly visible behavior.

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