Date: Fri, 14 Oct 2005 09:29:36 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Victor Sudakov <sudakov@sibptus.tomsk.ru> Cc: freebsd-fs@freebsd.org Subject: Re: Problem with default ACLs and mask Message-ID: <20051014092250.D66245@fledge.watson.org> In-Reply-To: <20051014064145.GA40856@admin.sibptus.tomsk.ru> References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051014092250.D66245>