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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.