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

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: J. Bruce Fields (bfields@fieldses.org)
Date: 12/16/04-02:33:56 PM Z


Date: Thu, 16 Dec 2004 15:33:56 -0500
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-ID: <20041216203356.GD7357@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>

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

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?  I assume that means that modifying
read and write bits on the parent file has no effect on the existing
attributes?

Do they also have their own owners, or does chown affect all
descendents?

And how are the permissions of the extended attribute directory determined?

--b.

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


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:48 AM Z CST