Problem with default ACLs and mask

Heinrich Rebehn rebehn at ant.uni-bremen.de
Fri Oct 14 05:51:53 PDT 2005


Robert Watson wrote:
> 
> On Fri, 14 Oct 2005, Victor Sudakov wrote:
> 
>> Heinrich Rebehn wrote:
>>
>>>
>>
>> [dd]
>>
>>> Am i doing something wrong here? Why is the mask not propagated?
>>
>>
>> I am afraid the current umask prevents it. You must set it to
>> something like "umask 002" before you create your files or directories
>> (the group write bit matters here).
> 
> 
> The problem, so to speak, is that we actually implement what is
> described in the POSIX.1e spec.  When we did our initial implementation,
> the various OS's varied a bit in the semantics they implemented:
> 
> - Solaris implemented umask override if the mask was specified in the
>   default ACL.

does umask override or is umask overriden? :-) I suppose the former.

> - IRIX implemented the spec.
> 
> Since that time, Linux has turned up and implemented the Solaris model,
> and IRIX has switched to the Solaris model also as a result of peer
> pressure.  I've previouly looked at switching us, but it tears up our
> kernel APIs some and will require significant testing.  I had hoped to
> do this for FreeBSD 6.x but was derailed working on other problems that
> needed to be fixed.  My hope is to change the default in FreeBSD 7.x.
> Doing this requires:
> 
> (1) All file creation VOP's to accept different fields -- rather than
>     accepting the completed creation mode, they need to accept the
>     creation mask and requested creation mode.
> 
> (2) The fairly dispersed current logic for combining the umask and
>     requested creation mask needs to be discovered, normalized, and
>     documented.  You'll notice if you grep around that the umask +
>     creation mode processing uses slightly different bit combination and
>     masking operations depending on object type.  Only code inspection
>     combined with some portability testing will tell us if what's there
>     now is a bug or a feature.
> 
> (3) Addition of logic to kern_acl.c so that file systems implementing
>     POSIX.1e can ask the revised question about initial ACL and file mode.
> 
> (4) Much testing.  Ideally, creastion of fairly extensive regression tests
>     having to do with the modes of files on creation, ACLs, etc.
> 
> There's also been a recent discussion on trustedbsd-discuss about
> implementing alternative semantics based on the NFSv4 ACL model.  I've
> taken a walk through the spec and a bit of initial hacking, and need to
> send e-mail to the NFSv4 working group mailing list asking for
> clarification of some points.  If we did do this, we would presumably
> add a new flag, nfsv4_acl, for UFS, to allow the administrator to select
> one of two models.  A further complexity is that these models are
> require different, and so we'd have to look carefully at tools and
> application behavior.
> 
> Robert N M Watson

Thanks for this in-depth explanation. This sounds like we cannot expect
a solution any time soon. I will think about another method of managing
our lab users (or use adjust umask - better than nothing).
I would really appreciate alternative models for NFS4.

--Heinrich


More information about the freebsd-fs mailing list