some questions about ACL implementation

[Robert Watson]

On Tue, 18 Mar 2003, ouyang kai wrote:

>    I am reading the ACL implementation based FreeBSD5.0 release. I have some 
> problems, please help.

Sorry about not answering sooner, I missed your message in my rather
excessive mailbox.

>    1. the 'extattrctl initattr -p / 388 posix1e.acl_access' command: why the 
> size is 388. the 'ufs_extattr_header' size is 12 and the 'acl' is 324, so 
> the sum is 336.

paprika:~/freebsd/tmp/acl> ./acl 
sizeof(struct acl) == 388

At least on my box ACL structures are 388 bytes, hence the size above.
ufs_extattr_header should be excluded from the EA header size for UFS1,
but if it's not, please let me know.  In theory, if you initialize a UFS1
backing file and request storage for 20 byte EAs, it should reserve enough
space for a complete 20 bytes of meta-data.

>    2. what is the relationship of ACL_GROUP_OBJ and ACL_MASK? If I do not 
> set the ACL EA, we can not get the information of 'ACL_MASK'. ACL_MASK 
> represents what?

The relationship between the group bits and the mask is "special" in
POSIX.1e -- I'll refer you to the document for details, but I can give the
high level idea here.  The concept is that some applications understand
only base permissions and umask, and that you want them to operate safely. 
If you do *not* have an extended ACL, then permissions should behave
exactly as if you didn't support ACLs.  If you do have an extended ACL,
then you *must* have a mask, and when operations like stat(), chmod(), and
umask act on ACLs, the group bits in the permission set are treated as
though the affect the mask and not the group entry.  For example, if an
extended ACL is present on a file, stat() will replace the normal group
permissions with the mask permissions, and chmod() will change the mask
rather than the group permissions.  Since the mask places an "upper bound"
on the rights described by the extended ACL, this makes chmod/stat/...
conservative from a permissions perspective.

Regarding the creation mask: some systems choose to override the umask
with the ACL mask, and some systems choose to intersect the two.  Right
now, we intersect since that's more conservative, but given that most
mainstream systems either use the mask or are switching to it (Solaris,
Linux, IRIX is switching), we will probably want to take the override
approach.  I have local patches that do most of that in the FreeBSD
perforce server, and I had hoped to merge them by 5.1.  Unfortunately, I'm
much more time-constrained than I had hoped, so that work is currently
stalled.  The basic thrust is that the logic for combining the mask and
requested creation mode has to be pushed into per-file system code, so you
pass the mask into each creation VOP as well as the mode, not the
intesection of the two.  This touches all the file systems, so is fairly
labor-intensive to implement.  While it is less conservative than the
intersection model, it is quite useful, since it permits default ACLs to
force permissions/ACLs to be more open than the umask requests, which is
good for "group project" sorts of environments.  When we do implement
these semantics, we'll probably support conditional use of either model
based on some flag or criteria (perhaps compile-time, perhaps mount-time). 

>    3. "As part of the ACL is stored in the inode, and the rest in an EA, 
> assemble both into a final ACL product. Right now this is not done very 
> efficiently.", Do you any viewpoint about that? How we can improve the 
> efficiency?

The biggest single performance improvement for ACLs was to move to UFS2,
which dramatically improves the performance of EA operations.  To get some
further improvement, we should use one of the in-inode flags to be a weak
consistency flag suggesting the presence of ACL data in the EA block, so
that we can avoid an EA read if none is present.  Weak consistency is
required because soft updates cannot guarantee that two independent block
writes must have ACID properties, it can only guarantee ordering.
Therefore the flag should offer the possibility of false positives rather
than false negatives :-).  It would be relatively easy to add this
support, but if doing so, we'd want to have convincing performance numbers
that suggest it was useful.  We've seen the vast majority of cost go away
with UFS2, so it might not be needed.

>    4. about ACL based on UFS2, do the ACLs of an inode store di_extb? Could 
> you introduce the ACLs' management on UFS2?

UFS2 fully supports ACLs; in fact, we recommend UFS2 over UFS1 for ACLs
because it's much faster and has better failure modes.  UFS2 ACLs are
stored in the EA extent pointed to by the inode, require less
administrative overhead (since you don't have to configure EA backing
files), etc, etc. 

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