RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES

bhalevy@panasas.com

Message-ID: <D72776FC4B13B64E9232562572AF292BF153DF@barrule.panasas.com>
From: "Halevy, Benny" <bhalevy@panasas.com>
Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Date: Thu, 16 Dec 2004 08:05:12 -0500

Lisa Week wrote:
> 
> J. Bruce Fields wrote:
> > On Wed, Dec 15, 2004 at 03:46:36PM -0500, Halevy, Benny wrote:
> > 
> >>Thinking about this again, the following model
> >>makes even more sense to me:
> >>
> >>- everyone can always read named attributes.
> >>- the owner can always write named attributes.
> >>- anyone that has permission to write the file
> >>  has permission to write its named attributes.
> >>
> >>- permission to write named attributes applies
> >>to the contents of named attributes as well
> >>as to creating, removing, and renaming named
> >>attributes.
> > 
> > 
> > I don't know whether that makes sense.
> 
> Agreed, those semantics don't make sense to us either.
> For the following reasons:
> 1.) In Solaris, it is not the default that everyone read 
> named attributes
> 2.) The owner can't always write named attributes (if they don't have 
> write permissions on the attribute, they can't modify it)

I like the model of having permissions/ACLs on the named attributes
themselves.  In Solaris what do {READ,WRITE}_NAMED_ATTRIBUTES
control?

> 
> > My goal here isn't really to
> > figure out how named attribute permissions should work.
> > 
> > The problems I'm currently trying to address are:
> > 
> > 	1. Some nfsv4 servers don't implement the full NFSv4 
> ACL protocol.
> > 	   The Linux server, for example, is supporting POSIX 
> acls only for
> > 	   the time being, because that's all our backend 
> filesystems support.
> 
> Solaris is also supporting POSIX acls.  This is because currently, 
> Solaris typically uses UFS on the server and that is limited only 
> interpreting/storing POSIX acls.
> 
> > 	2. It's easy to expose full NFSv4 ACLs to users on clients.
> > 	   However, a number of clients have preexisting POSIX ACL
> > 	   interfaces, and want to continue supporting applications and
> > 	   users that may depend on them.
> 
> Yup.
> 
> > 
> > For example, I'd like it to be possible for a user to set a 
> posix acl on
> > a file over NFSv4.  This requires translating the posix acl 
> they provide
> > into an NFSv4 acl whose effect is something like what they'd expect.
> > 
> 
> This is what the Internet Draft, in our opinion, did very nicely.  I 
> don't think we should be so quick to discard that work...
> 
> > The best thing in this case may be to leave
> > {READ,WRITE}_NAMED_ATTRIBUTES completely unspecified and 
> leave it up the
> > the server.  On a linux server that will have the same effect as the
> > current mapping, since there's no way for a linux server to decouple
> > {READ,WRITE}_NAMED_ATTRIBUTES from read/write permissions.  
> On another
> > server that may have some other effect.
> 
> Something we recently discovered is that on Solaris, 
> {READ,WRITE}_NAMED_ATTRIBUTES is coupled with read/write 
> permissions of 
> the file only upon creation of the named attributes.  With subsequent 
> changes of the permissions of the file, the named attributes 
> permissions 
> will remain the same.  The named attributes permissions can also be 
> changed independent of the file permissions.
> 
> Leaving {READ,WRITE}_NAMED_ATTRIBUTES unspecified would be 
> alright with 
> us since POSIX acls don't and can't actually control the 
> ability to read 
> and write named attributes.  We'd be using the same logic as was used 
> with ACE4_DELETE and ACE4_WRITE_OWNER.
> 
> > 
> > In fact, it may be that we should throw out this whole complicated
> > specification of mode bits and just use:
> > 
> > 	r->READ_DATA
> > 	w->WRITE_DATA
> > 	x->EXECUTE
> > 
> > Since the server behaviour is undefined when bits are left 
> unspecified,
> > we could leave all the bits other than READ_DATA, WRITE_DATA, and
> > EXECUTE unset in every allow and deny ace, and depend on 
> the server to
> > do the right thing.
> 
> Don't know if we should really throw out ACE4_APPEND_DATA 
> from the POSIX 
> write bit translation.  If we really look at it, the 
> definition of the 
> POSIX write bit also allows an entity the ability to APPEND_DATA. 
> Right?  What does it buy us to leave APPEND_DATA 
> unspecified...if it can 
> actually be mapped correctly?
> 
> > 
> > Most of the language in our draft about what NFSv4 mode 
> bits should be
> > set would then become recommendations about how servers 
> should determine
> > what to do when they fall off the bottom of an acl, if they want to
> > provide posix-like clients the permissions they expect.
> 
> Yeah, actually we think that it would be really helpful for the bits 
> that are left unspecified when mapping NFSv4<->POSIX.
> 
> In that same thought, we should not start leaving a whole bunch of 
> things unspecified.  We should only leave the bits 
> unspecified that we 
> absolutely have to...or in other words, ones that don't map at all to 
> POSIX acls.
> 
> > 
> > For example, if an ACL allows WRITE, and doesn't deny 
> APPEND_DATA, then
> > a server should by default allow APPEND_DATA.  If an ACL 
> doesn't deny
> > WRITE_ATTRIBUTES to the owner then the client should assume it's
> > permitted.  Etc.
> > 
> > In fact, I rather like that idea.  It seems a great deal 
> simpler than
> > what we have now.  
> 
> >Objections?
> 
> Yes!
> 
> We don't think it is good to move in a direction of leaving things 
> unspecified (if they can validly be specified).
> 
> We don't think we should steer far from what the I-D already 
> articulated....
> 
> With some modifications for what we have been discussing, 
> that would mean:
> 
> r -> ACE4_READ_DATA
> w -> ACE4_WRITE_DATA | ACE4_APPEND_DATA | ACE4_DELETE_CHILD 
> (only if the 
> file system object is a directory)
> x -> ACE4_EXECUTE
> 
> Everyone gets ALLOWED ACE4_READ_ATTRIBUTES, ACE4_READ_ACL and 
> ACE4_SYNCHRONIZE
> Everyone (except OWNER@) gets DENIED ACE4_WRITE_ATTRIBUTES
> OWNER@ gets ALLOWED ACE4_WRITE_ATTRIBUTES and ACE4_WRITE_ACL
> 
> 
> ACE4_WRITE_OWNER is unspecified
> 	Servers can interpret this as:
> 		Only a privileged user (root or maybe the 
> OWNER@) can write the owner.
> ACE4_DELETE is unspecified
> 	Servers can interpret this as:
> 		Look at the parent directory to determine the 
> ability to delete file. 
> (is ACE4_DELETE_CHILD ALLOWed on the parent directory's ACL?)
> ACE4_READ_NAMED_ATTRS is unspecified
> ACE4_WRITE_NAMED_ATTRS is unspecified
> 
> Thanks,
> Sam and Lisa
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4