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

Lisa.Week@Sun.COM

Date: Wed, 15 Dec 2004 19:16:21 -0700
From: Lisa Week <Lisa.Week@Sun.COM>
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-id: <41C0EFF5.1020403@Sun.COM>

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)

> 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