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

bfields@fieldses.org

Date: Thu, 16 Dec 2004 15:19:12 -0500
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-ID: <20041216201912.GB7357@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>

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.

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

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

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.
	* 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.
	* 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.)

--b.

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