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

bhalevy@panasas.com

Message-ID: <D72776FC4B13B64E9232562572AF292BF153DC@barrule.panasas.com>
From: "Halevy, Benny" <bhalevy@panasas.com>
Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
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: nfsv4-bounces@ietf.org 
> [mailto:nfsv4-bounces@ietf.org]On Behalf Of
> Halevy, Benny
> Sent: Wednesday, December 15, 2004 10:26 PM
> To: 'J. Bruce Fields'
> Cc: Sam Falkner; nfsv4@ietf.org; 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: nfsv4-bounces@ietf.org 
> > [mailto:nfsv4-bounces@ietf.org]On Behalf Of
> > J. Bruce Fields
> > Sent: Wednesday, December 15, 2004 9:44 PM
> > To: Lisa Week
> > Cc: Sam Falkner; nfsv4@ietf.org
> > 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
> > nfsv4@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> > 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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