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

From: "Halevy, Benny" <[email-masked]>
Date: Wed, 15 Dec 2004 15:46:36 -0500

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.

Benny

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Halevy, Benny
> Sent: Wednesday, December 15, 2004 10:26 PM
> To: 'J. Bruce Fields'
> Cc: Sam Falkner; [email-masked]; Lisa Week
> Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
> 
> 
> Bruce, why do you map the {READ,WRITE}_NAMED_ATTRIBUTES
> to the {r,w} permission bits which control access
> to the file's *data* rather than mapping them the
> same as {READ,WRITE}_ATTRIBUTES - read allowed by
> everyone, write allowed to owner?
> 
> Since the NFS client determines what's
> stored in the file's named attributes I think
> that coupling named attrs permission with
> *data* r/w permission is wrong as I assume
> that the contents of the named attributes are going
> to be client O/S or application *metadata*
> like filename in 8.3 format, file description,
> author, track #, etc.
> 
> It makes more sense to me that the permission to
> access a file's named attributes should be the
> same as the permission to access the file's 
> attributes as an extension to the Unix permission
> model.
> 
> For example, why can't the owner of a read only file
> (or directory) modify its named attributes? 
> 
> Are you sure you want to allow anyone to update the
> named attributes for a writeable file (modifyable
> directory)?
> 
> Are you sure you want to disallow anyone from
> reading a file's named attributes if the file
> data is not readable (directory not listable)?
> 
> Benny
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On Behalf Of
> > J. Bruce Fields
> > Sent: Wednesday, December 15, 2004 9:44 PM
> > To: Lisa Week
> > Cc: Sam Falkner; [email-masked]
> > Subject: Re: [nfsv4] NFSv4 ACLs: ACE4_WRITE_ATTRIBUTES clarification
> > 
> > 
> > So I think that the current proposal for how to use the 14 
> bits in v4
> > ace bitmasks when mapping between v4 and posix acls is this:
> > 
> > 	Everyone is given READ_ATTRIBUTES | READ_ACL | SYNCHRONIZE.
> > 	The owner is given WRITE_ATTRIBUTES | WRITE_ACL.
> > 
> > 	Other bits depend on mode bits:
> > 
> > 	r-> READ_DATA | READ_NAMED_ATTRS
> > 	w-> WRITE_DATA | WRITE_NAMED_ATTRS | APPEND_DATA | DELETE_CHILD
> > 	x-> EXECUTE
> > 
> > 	DENY aces are given a bit mask that is the complement of
> > 	the bit mask determined as above, except that we never set any
> > 	bits not named in the protocol, and we never set the DELETE
> > 	or WRITE_OWNER bits.
> > 
> > Have I gotten anything wrong in the description above?
> > 
> > The Linux implementation doesn't do WRITE_OWNER as above, so 
> > I intend to fix
> > that.  There's some disagreement over the 
> > {READ,WRITE}_ATTRIBUTES bits as no
> > one knows what they're for.  Also, I would rather treat 
> > SYNCHRONIZE like DELETE
> > and WRITE_OWNER, but the choice is somewhat arbitrary and 
> > allowing SYNCHRONIZE
> > is what everyone else is doing at this point and what Windows 
> > clients seem to
> > prefer as the default.
> > 
> > --b.
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> > 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 15 Dec 2004 16:49:08 -0500

> as to creating, removing, and renaming named

I don't know whether that makes sense.  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.
	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.

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.

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.

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.

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.

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?

--b.

---

From: Lisa Week <[email-masked]>
Date: Wed, 15 Dec 2004 19:16:21 -0700

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

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.

> 	   users that may depend on them.

Yup.

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

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

> EXECUTE unset in every allow and deny ace, and depend on the server to

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?

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

> 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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 16 Dec 2004 15:19:12 -0500

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

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