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

gww@traakan.com

From: "Gordon Waidhofer" <gww@traakan.com>
Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Date: Thu, 16 Dec 2004 11:42:26 -0800
Message-ID: <HIEGIBOPEMBFAKKGEELDGEJKJAAA.gww@traakan.com>

The question of NFSV4_{READ|WRITE}_NAMED_ATTRIBUTES
should be deferred for as long as possible, certainly
in the near term. Why? Simply because there is unspoken
discord about what a named attribute is.

The rub is that the names of many things bear
superficial resemblence even though the underlying
mechanisms are disperate.

Solaris "Named Attribute" is a terrific implementation
of named subfiles, or named streams. Capacity of
a named subfile is unlimited. Content is opaque.
Access is through read/write.

Linux, FreeBSD, et al, have "Extended Attributes".
The interface, getxattr(), is really like ioctl()
using a textual name rather than a small integer name.
Capacity is small and usually (should be) defined
by the system. Content is non-opaque. Access is
through get/set style interface.

Values are monolithic and audited at setxattr() time.
Consider this: could chmod(2) be implemented as
a set of eight unordered writes? How about POSIX
ACLs and 1000+ unordered writes? It's quite
impractical. Further, the getxattr()/setxattr()
operands are typically translated by the underlying
file system into a native data structure. Each
file system does things differently.

THERE IS NO SUCH THING AS AN OPAQUE ATTRIBUTES.
NFSv4 transfers opaque data with READ/WRITE.
Attributes are transfered by formal definition
and XDR encoding.

Ultimately, everybody should steer toward Solaris
style named subfiles. Solaris should rename the
mechanism. So should NFSv4.

Solaris, FreeBSD, and everybody should implement
a getxattr()/setxattr() interface, even as a
compatability library. Yes, indeed, Solaris too
can getxattr("posix_acl", &x).

And all that is where the story starts. NT has
subfiles that do not have independent permissions.
That is likely to change. I'm told the Hummingbird
folks are looking at implemented NFSv4 Named Attributes
as NT "streams". I'm also told that Microsoft is
letting go legacy file systems that have restrained
MS applications using streams, and hence we can expect
growing requirements to support streams (named subfiles).

More can be found here:

   http://www.nfsconf.com/pres04/waidhofer.pdf

NFSv4 is really in good shape. Named Attributes are
really named subfiles. Folks just keep stubing there
toes on the similarity of names between Named Attribute
and Extended Attributes. The names are too similar
for disperate mechanisms. Folks read intent into
the similarity of the names. "Hmm, similar names,
so the drafters surely intended that Named Attributes
as Extended Attributes." Nope. Just an unfortunate
and understandable mistake.

You may not agree with all that. But you can't
safely ignore it, either.

Hence, until there is better understanding and
concurence about how "Named Thingies" fit into
the file model, it's best to defer decisions
about NFSv4_{READ|WRITE}_NAMED_ATTRIBUTES.

Regards,
	-gww

> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org]On Behalf Of
> Halevy, Benny
> Sent: Thursday, December 16, 2004 5:05 AM
> To: 'Lisa.Week@Sun.COM'; J. Bruce Fields; nfsv4@ietf.org
> Cc: Sam.Falkner@Sun.COM
> Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
> 
> 
> Lisa Week wrote:
> > 
> > J. Bruce Fields wrote:
> > > On Wed, Dec 15, 2004 at 03:46:36PM -0500, Halevy, Benny wrote:
> > > 
> > >>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.
> > > 
> > > 
> > > I don't know whether that makes sense.
> > 
> > Agreed, those semantics don't make sense to us either.
> > For the following reasons:
> > 1.) In Solaris, it is not the default that everyone read 
> > named attributes
> > 2.) The owner can't always write named attributes (if they don't have 
> > write permissions on the attribute, they can't modify it)
> 
> I like the model of having permissions/ACLs on the named attributes
> themselves.  In Solaris what do {READ,WRITE}_NAMED_ATTRIBUTES
> control?
> 
> > 
> > > My goal here isn't really to
> > > figure out how named attribute permissions should work.
> > > 
> > > The problems I'm currently trying to address are:
> > > 
> > > 	1. Some nfsv4 servers don't implement the full NFSv4 
> > ACL protocol.
> > > 	   The Linux server, for example, is supporting POSIX 
> > acls only for
> > > 	   the time being, because that's all our backend 
> > filesystems support.
> > 
> > Solaris is also supporting POSIX acls.  This is because currently, 
> > Solaris typically uses UFS on the server and that is limited only 
> > interpreting/storing POSIX acls.
> > 
> > > 	2. It's easy to expose full NFSv4 ACLs to users on clients.
> > > 	   However, a number of clients have preexisting POSIX ACL
> > > 	   interfaces, and want to continue supporting applications and
> > > 	   users that may depend on them.
> > 
> > Yup.
> > 
> > > 
> > > For example, I'd like it to be possible for a user to set a 
> > posix acl on
> > > a file over NFSv4.  This requires translating the posix acl 
> > they provide
> > > into an NFSv4 acl whose effect is something like what they'd expect.
> > > 
> > 
> > This is what the Internet Draft, in our opinion, did very nicely.  I 
> > don't think we should be so quick to discard that work...
> > 
> > > The best thing in this case may be to leave
> > > {READ,WRITE}_NAMED_ATTRIBUTES completely unspecified and 
> > leave it up the
> > > the server.  On a linux server that will have the same effect as the
> > > current mapping, since there's no way for a linux server to decouple
> > > {READ,WRITE}_NAMED_ATTRIBUTES from read/write permissions.  
> > On another
> > > server that may have some other effect.
> > 
> > Something we recently discovered is that on Solaris, 
> > {READ,WRITE}_NAMED_ATTRIBUTES is coupled with read/write 
> > permissions of 
> > the file only upon creation of the named attributes.  With subsequent 
> > changes of the permissions of the file, the named attributes 
> > permissions 
> > will remain the same.  The named attributes permissions can also be 
> > changed independent of the file permissions.
> > 
> > Leaving {READ,WRITE}_NAMED_ATTRIBUTES unspecified would be 
> > alright with 
> > us since POSIX acls don't and can't actually control the 
> > ability to read 
> > and write named attributes.  We'd be using the same logic as was used 
> > with ACE4_DELETE and ACE4_WRITE_OWNER.
> > 
> > > 
> > > In fact, it may be that we should throw out this whole complicated
> > > specification of mode bits and just use:
> > > 
> > > 	r->READ_DATA
> > > 	w->WRITE_DATA
> > > 	x->EXECUTE
> > > 
> > > Since the server behaviour is undefined when bits are left 
> > unspecified,
> > > we could leave all the bits other than READ_DATA, WRITE_DATA, and
> > > EXECUTE unset in every allow and deny ace, and depend on 
> > the server to
> > > do the right thing.
> > 
> > Don't know if we should really throw out ACE4_APPEND_DATA 
> > from the POSIX 
> > write bit translation.  If we really look at it, the 
> > definition of the 
> > POSIX write bit also allows an entity the ability to APPEND_DATA. 
> > Right?  What does it buy us to leave APPEND_DATA 
> > unspecified...if it can 
> > actually be mapped correctly?
> > 
> > > 
> > > Most of the language in our draft about what NFSv4 mode 
> > bits should be
> > > set would then become recommendations about how servers 
> > should determine
> > > what to do when they fall off the bottom of an acl, if they want to
> > > provide posix-like clients the permissions they expect.
> > 
> > Yeah, actually we think that it would be really helpful for the bits 
> > that are left unspecified when mapping NFSv4<->POSIX.
> > 
> > In that same thought, we should not start leaving a whole bunch of 
> > things unspecified.  We should only leave the bits 
> > unspecified that we 
> > absolutely have to...or in other words, ones that don't map at all to 
> > POSIX acls.
> > 
> > > 
> > > For example, if an ACL allows WRITE, and doesn't deny 
> > APPEND_DATA, then
> > > a server should by default allow APPEND_DATA.  If an ACL 
> > doesn't deny
> > > WRITE_ATTRIBUTES to the owner then the client should assume it's
> > > permitted.  Etc.
> > > 
> > > In fact, I rather like that idea.  It seems a great deal 
> > simpler than
> > > what we have now.  
> > 
> > >Objections?
> > 
> > Yes!
> > 
> > We don't think it is good to move in a direction of leaving things 
> > unspecified (if they can validly be specified).
> > 
> > We don't think we should steer far from what the I-D already 
> > articulated....
> > 
> > With some modifications for what we have been discussing, 
> > that would mean:
> > 
> > r -> ACE4_READ_DATA
> > w -> ACE4_WRITE_DATA | ACE4_APPEND_DATA | ACE4_DELETE_CHILD 
> > (only if the 
> > file system object is a directory)
> > x -> ACE4_EXECUTE
> > 
> > Everyone gets ALLOWED ACE4_READ_ATTRIBUTES, ACE4_READ_ACL and 
> > ACE4_SYNCHRONIZE
> > Everyone (except OWNER@) gets DENIED ACE4_WRITE_ATTRIBUTES
> > OWNER@ gets ALLOWED ACE4_WRITE_ATTRIBUTES and ACE4_WRITE_ACL
> > 
> > 
> > ACE4_WRITE_OWNER is unspecified
> > 	Servers can interpret this as:
> > 		Only a privileged user (root or maybe the 
> > OWNER@) can write the owner.
> > ACE4_DELETE is unspecified
> > 	Servers can interpret this as:
> > 		Look at the parent directory to determine the 
> > ability to delete file. 
> > (is ACE4_DELETE_CHILD ALLOWed on the parent directory's ACL?)
> > ACE4_READ_NAMED_ATTRS is unspecified
> > ACE4_WRITE_NAMED_ATTRS is unspecified
> > 
> > Thanks,
> > Sam and Lisa
> > 
> > _______________________________________________
> > 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