Re: NFS4 ACL <-> Posix ACL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux