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

Saadia.Khan@netapp.com

Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Date: Thu, 16 Dec 2004 15:49:23 -0800
Message-ID: <482A3FA0050D21419C269D13989C611303D87B00@lavender-fe.eng.netapp.com>
From: "Khan, Saadia" <Saadia.Khan@netapp.com>

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

> - Sam
> 
> 
> _______________________________________________
> 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