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

bhalevy@panasas.com

Message-ID: <D72776FC4B13B64E9232562572AF292BF153DA@barrule.panasas.com>
From: "Halevy, Benny" <bhalevy@panasas.com>
Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
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: 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