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

Sam.Falkner@Sun.COM

Date: Fri, 07 Jan 2005 16:46:55 -0700
From: Sam Falkner <Sam.Falkner@Sun.COM>
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-id: <ii7sm5c6bv4.fsf@central.sun.com>

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Wed, Dec 15, 2004 at 07:16:21PM -0700, Lisa Week wrote:
>> 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.

> Yes, with the slight difference that we probably shouldn't be rejecting
> acls that do explicitly set {READ,WRITE}_NAMED_ATTRIBUTES in tandem with
> read/write--it does no harm to accept ACLs that describe the behaviour
> we enforce anyway.

Okay, we've decided to accept ACLs with {READ,WRITE}_NAMED_ATTRIBUTES
set, and only reject them if they are in a DENY ACE that we cannot
enforce, because we don't want to accept an ACL that makes us appear
more secure than we are.

>> 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?

> Sorry, APPEND_DATA wasn't the best example.  Consider WRITE_ATTRIBUTES:
> we'd rather servers allow WRITE_ATTRIBUTES to the owner and no one else,
> but if some wacky server insists that WRITE_ATTRIBUTES always match
> WRITE, why sacrifice ACL interoperability over this point?

> It might be better just to neither allow nor deny WRITE_ATTRIBUTES in
> our acls and to leave it up to the server to enforce a reasonable
> default.  For unix-like servers, that default will be what we expect,
> for others, it won't, oh well--we're stuck with that--but at least we'll
> still be able to read and write basic ACLs.

> If some client really really wants to insist on WRITE_ATTRIBUTES being
> right, then let them go ahead and set it all the time, and if you're a
> unix-like server, allow them to do that as long as they're setting it in
> the way you expect, but let's not require that clients be that strict.

We feel that if an access_mask bit can be mapped to POSIX behavior,
then it should be mapped, rather than left unspecified.  That way, we
ensure POSIX behavior, rather than leaving it up to the server's
implementation.

In the case of WRITE_ATTRIBUTES, it can be mapped correctly with POSIX
behavior, so we will continue to specify and require WRITE_ATTRIBUTES
as it is defined in the I-D.  An improvement that could be made to the
I-D would be to specify exactly what WRITE_ATTRIBUTES means (as we
have done previously in this email thread).

>> J. Bruce Fields wrote:
>> >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....

> OK, OK, I don't really want to throw out the I-D.  But I do want to
> at least make a couple additional suggestions for implementations:
> 	1. When doing nfsv4->posix translation, if the given nfsv4 acl
> 	   leaves some bits neither allowed nor denied, translation should
> 	   still succeed as long as it contains nothing that would directly
> 	   contradict the I-D (like an allow of WRITE and a deny of APPEND
> 	   to the same entity).
> 	2. When doing posix->nfsv4 translation, it may sometimes be
> 	   advantageous to count on the translation behaving as in #1,
> 	   and to send a more "minimal" acl across the wire.

> I think #2 is more likely to be contraversial than #1.

See our summary at the bottom on this...

> The advantages I see are:
> 	* A more forgiving nfsv4->posix acl mapping, as in #1 above,
> 	  makes it possible to set raw nfsv4 acls on a posix server without
> 	  requiring users to memorize the whole mapping.

We think the complexity of creating a POSIX-conformant ACL should be
handled by the user interfaces, rather than requiring the user to
craft a POSIX-conformant ACL by hand.

> 	* If the server returns simpler ACLs, as in #2, then a
> 	  user looking at the raw NFSv4 ACL has a better chance of
> 	  understanding it.

Again, we would hope that the user interface would help the user with
this.

> 	* If the client sends simpler ACLs, as in #2, then we improve the
> 	  chances of interoperability with servers with slightly
> 	  different permissions models--see the WRITE_ATTRIBUTES example
> 	  above.

> I'm assuming that even servers that support independent enforcement of
> every bit in the NFSv4 ACL bit mask can actually enforce reasonable
> defaults in the presence of acls that neither allow nor deny those bits.

> I suppose a server could say "this ACL doesn't explicitly allow
> READ_ATTRIBUTES, so I must assume that the user meant to deny it!" That
> strikes me as dumb behaviour.  Maybe someone else can defend it.

> In any case, I think we can agree at least on #1.  I also think we
> should agree on #2 for servers returning acls.  (But maybe clients
> setting acls should be more explicit.)

In cases where the access_mask doesn't translate to POSIX behavior
(e.g. ACE4_SYNCHRONIZE, ACE4_DELETE, ACE4_WRITE_NAMED_ATTRS,
ACE4_READ_NAMED_ATTRS), we have become more lenient.  We still give
errors when the user tries to set an ACL that would make the file
appear to be more secure than it really is.  This is where we will be
changing from the current I-D.

In cases where access_mask does translate to POSIX behavior
(e.g. ACE4_WRITE_ATTRIBUTES), we will stay with the behavior specified
in the I-D; in other words, we'll specify and require these masks as
they are documented in the I-D.  This will provide for consistent
behavior, with minimal surprises for the users, especially when
operating across different vendors' implementations.  If a user is
setting a POSIX-draft ACL, wouldn't they expect POSIX behaviors?
Specifying and requiring as much as possible, when it correctly maps
to POSIX behaviors, should ensure that the users get the behavior they
are expecting.

Based on the summary above, we have made the changes to our
implementation that we feel comfortable with.  Attached is a document
describing what the behavior of Solaris will be.

- Sam Falkner
  Lisa Week