From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Alex Bremer <albremer@googlemail.com>, linux-nfs@vger.kernel.org
Subject: Re: NFS4 ACL <-> Posix ACL
Date: Tue, 24 Mar 2009 19:57:46 -0400 [thread overview]
Message-ID: <20090324235746.GA26452@fieldses.org> (raw)
In-Reply-To: <1237936852.7516.50.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
On Tue, Mar 24, 2009 at 07:20:52PM -0400, Trond Myklebust wrote:
> On Tue, 2009-03-24 at 19:02 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 24, 2009 at 06:54:41PM -0400, Trond Myklebust wrote:
> > > On Tue, 2009-03-24 at 18:34 -0400, J. Bruce Fields wrote:
> > > > On Tue, Mar 24, 2009 at 06:22:47PM -0400, Trond Myklebust wrote:
> > > > > On Tue, 2009-03-24 at 18:15 -0400, J. Bruce Fields wrote:
> > > > > > On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > > > > > > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > > > > > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > > > > > > >> How do other people share public files with NFS4? If there is no other
> > > > > > > > > >> way than setting the users's umask to 002, this would practically
> > > > > > > > > >> limit the use of NFS4 to private shares like home directories.
> > > > > > > > > >
> > > > > > > > > > I don't understand why--can't you use the user-private-group trick?:
> > > > > > ...
> > > > > > > > > - we actually have directories where files should only be group readable.
> > > > > > > >
> > > > > > > > I don't get it--why not set an inheritable acl on those directories that
> > > > > > > > permits only read to the group?
> > > > > > >
> > > > > > > That only works if the client actually respects the acl...
> > > > > >
> > > > > > I don't understand. ACL enforcement and inheritance are both done on
> > > > > > the server side.
> > > > > >
> > > > > > The problem is just that the umask is applied on the client side. But
> > > > > > if the umask is 002, and an inheritable ACL permits only read, then the
> > > > > > result of inheritance and umask-application will be an ACL that permits
> > > > > > reads (and only reads) to the group owner (and to any named users and
> > > > > > groups).
> > > > >
> > > > > The client currently always sends a mode. My interpretation of RFC3530
> > > > > is that this will always override the inherited ACL (see the discussion
> > > > > in OP_OPEN and OP_CREATE w.r.t. the createattrs field).
> > > >
> > > > Depends on what you mean by "override". It shouldn't be replacing the
> > > > inherited ACL wholesale; see 6.4.3.
> > >
> > > That is the v4.1 draft, which is hardly normative for NFSv4.0 servers.
> > > Note, however, that in the v4.1 case too, the server is required to
> > > replace the OWNER@, GROUP@ and EVERYONE@ fields when the client sends a
> > > mode attribute (afaics from 6.4.1.1).
> >
> > Sure, but there's no need to blow away ACEs for named users and
> > groups--anyone that cares about posix should be restricting them to
> > grant no more than the mode group bits, but that's all.
>
> The client still needs to know whether or not it should apply the umask.
> I therefore don't see how changing server behaviour to the above can
> solve the problem in practice.
Yeah, throwing out the umaskless-mode doesn't help unless it we also
have something like the mode_set_masked.
--b.
next prev parent reply other threads:[~2009-03-24 23:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 17:42 NFS4 ACL <-> Posix ACL Alex Bremer
[not found] ` <7f62dcb30903181042n42bae0bbk99f5c91fce6e9e82-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-03-19 19:35 ` J. Bruce Fields
2009-03-23 13:46 ` Alex Bremer
[not found] ` <7f62dcb30903230646u183c79e0i4366edebe32654d5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-03-23 21:33 ` J. Bruce Fields
2009-03-24 1:56 ` Alex Bremer
[not found] ` <7f62dcb30903231856h7a17cea5ud7a22796ddfb6383-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-03-24 20:10 ` J. Bruce Fields
2009-03-24 21:44 ` Trond Myklebust
[not found] ` <1237931047.7516.15.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-03-24 22:15 ` J. Bruce Fields
2009-03-24 22:22 ` Trond Myklebust
[not found] ` <1237933367.7516.27.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-03-24 22:34 ` J. Bruce Fields
2009-03-24 22:54 ` Trond Myklebust
[not found] ` <1237935281.7516.40.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-03-24 23:02 ` J. Bruce Fields
2009-03-24 23:20 ` Trond Myklebust
[not found] ` <1237936852.7516.50.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-03-24 23:57 ` J. Bruce Fields [this message]
2009-03-24 22:21 ` J. Bruce Fields
2009-03-24 22:28 ` Trond Myklebust
[not found] ` <1237933686.7516.31.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-03-24 22:39 ` J. Bruce Fields
2009-03-24 3:09 ` Greg Banks
2009-03-24 12:08 ` Alex Bremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090324235746.GA26452@fieldses.org \
--to=bfields@fieldses.org \
--cc=Trond.Myklebust@netapp.com \
--cc=albremer@googlemail.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox