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

Lisa.Week@Sun.COM

Date: Thu, 16 Dec 2004 17:49:15 -0700
From: Lisa Week <Lisa.Week@Sun.COM>
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-id: <41C22D0B.9070001@Sun.COM>

Khan, Saadia wrote:
> 
>>-----Original Message-----
>>From: Sam Falkner [mailto:Sam.Falkner@Sun.COM] 
>>Sent: Thursday, December 16, 2004 1:25 PM
>>To: J. Bruce Fields
>>Cc: Halevy, Benny; nfsv4@ietf.org; 'Lisa.Week@Sun.COM'
>>Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
>>
>>
>>"J. Bruce Fields" <bfields@fieldses.org> writes:
>>
>>
>>>On Thu, Dec 16, 2004 at 01:23:41PM -0700, Sam Falkner wrote:
>>>
>>>>"Halevy, Benny" <bhalevy@panasas.com> writes:
>>>>
>>>>>I like the model of having permissions/ACLs on the named 
>>
>>attributes 
>>
>>>>>themselves.  In Solaris what do {READ,WRITE}_NAMED_ATTRIBUTES 
>>>>>control?
>>
>>>>A Solaris server using UFS as its filesystem only has POSIX-draft 
>>>>ACLs.  ACE4_{READ,WRITE}_NAMED_ATTRIBUTES aren't 
>>
>>represented at all 
>>
>>>>in these ACLs.  Mapping between these two different ACL models is 
>>>>what the I-D describes.
>>>>
>>>>But we've taken ACE4_{READ,WRITE}_NAMED_ATTRS to mean the 
>>
>>ability to 
>>
>>>>read or write extended attributes, as manipulated by the runat 
>>>>command in Solaris.
>>>
>>>Ignoring v4 acls for the moment, how do extended attribute 
>>
>>permissions 
>>
>>>work?  Feel free to refer me to a man page....
>>
>>The runat(1) man page mentions permissions on extended 
>>attributes, but you're correct below...
>>
>>
>>>It sounds like they have their own complete set of mode 
>>
>>bits and posix 
>>
>>>acls that can be set independently, but whose initial value depends 
>>>somehow on that of the parent file?
>>
>>Yes, that is correct.
>>
>>
>>>I assume that means that modifying read and write bits on 
>>
>>the parent 
>>
>>>file has no effect on the existing attributes?
>>
>>Correct.
>>
>>
>>>Do they also have their own owners, or does chown affect all 
>>>descendents?
>>
>>Yes, they have their own owners.  Chowning the file does not 
>>change the ownership of the attributes, but they can be 
>>chowned explicitly.
>>
>>
>>>And how are the permissions of the extended attribute directory 
>>>determined?
>>
>>When the first extended attribute is created, the permissions 
>>of the extended attribute directory are determined by the 
>>permissions on the file.  Essentially, it's the same as the 
>>file, but the search bit will be turned on as well.
>>
>>But after the extended attribute directory has been created, 
>>it can have its permissions changed at any time, independent 
>>of the file.
>>
> 
> 
> AFAIK, only the size attribute of a named attribute can be changed, any
> other setattr calls on a named attribute are denied. Atleast that's what
> I remember testing with solaris a couple of years back and that's what
> the Netapp server implements. Is that not true for solaris?

Do you recall specifically what you were testing?  We just did some 
simple tests and saw things like chmoding an extended attribute over 
nfsv4 succeed.

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