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

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

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

---

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

> everyone, write allowed to owner?

I checked Linux and (if I remember correctly) FreeBSD, and they both
used the {r,w} permission bits.

I'd welcome examples of unix-like OS's that do something different.

> stored in the file's named attributes

On Linux at least most named attributes are controlled by userspace, not
by the nfs client specifically, and those that aren't (system.posix_acl
and system.posix_acl are currently the only ones we care about) I expect
to be handled as special cases on the client.

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

In the last 3 of your examples, at least, it only makes sense to me to
couple the attribute permissions with data read/write permissions, since
those attributes are likely to need updating when the file contents
change.

Any change in the posix<->nfsv4 acl mapping should be in the direction
of just leaving out the NAMED_ATTRIBUTES bits entirely rather than
allowing to the owner and denying to others.

--b.