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

From: "Halevy, Benny" <[email-masked]>
Date: Thu, 16 Dec 2004 08:05:12 -0500

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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Thu, 16 Dec 2004 11:42:26 -0800

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: [email-masked] [mailto:[email-masked]]On Behalf Of
> Halevy, Benny
> Sent: Thursday, December 16, 2004 5:05 AM
> To: [email-masked]'; J. Bruce Fields; [email-masked]
> Cc: [email-masked]
> Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
> 
> 
> Lisa Week wrote:
> > 
> > J. Bruce Fields wrote:

---

From: Sam Falkner <[email-masked]>
Date: Thu, 16 Dec 2004 13:23:41 -0700

> themselves.  In Solaris what do {READ,WRITE}_NAMED_ATTRIBUTES

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.

- Sam & Lisa

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 16 Dec 2004 15:33:56 -0500

> read or write extended attributes, as manipulated by the runat command

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.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 16 Dec 2004 15:56:06 -0500

> discord about what a named attribute is.

I agree about the {READ|WRITE}_NAMED_ATTRIBUTES bits.

> through get/set style interface.

Under Linux, extended attributes with names beginning with "user." are
entirely up to userspace to manage, and are opaque as far as the kernel
is concerned.  Others (such as "system.posix_acl") may have structure.
I think the upper limit on content is on the order of 64k.

There's some interest in adding a named attribute interface closer to
that of NFSv4's or Solaris's, but not much work done on it yet as far as
I know.

--b.

---

From: Sam Falkner <[email-masked]>
Date: Thu, 16 Dec 2004 14:24:55 -0700

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

> 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

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

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.

- Sam

---

From: Lisa Week <[email-masked]>
Date: Thu, 16 Dec 2004 16:00:51 -0700

> I agree about the {READ|WRITE}_NAMED_ATTRIBUTES bits.

Just to be clear...What are we actually saying with "The question of 
NFSV4_{READ|WRITE}_NAMED_ATTRIBUTES should be deferred for as long as 
possible"?  Go with the I-D interpretation?  Leave them unspecified? 
Something else?

Thanks.
Lisa

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 16 Dec 2004 18:18:30 -0500

> possible"?  Go with the I-D interpretation?  Leave them unspecified? 

I think we should recommend that on posix->nfsv4 translation, we create
acls with neither bit set in any allow or deny ace.  On nfsv4->posix
translation we should ignore that bit whenever possible, that is,
whenver it doesn't force us into a lie.  (A Linux server, for example,
will reject an acl that explicitly denies WRITE_NAMED_ATTRIBUTES
when WRITE is explicitly allowed.)

I think that's approximately what we already agreed on?

The point is that if clients follow the current I-D then they force a
certain permissions model onto servers, which is probably a mistake.

--b.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 16 Dec 2004 21:56:46 -0500

> mechanism. So should NFSv4.

I disagree.  I can very easily forsee a future where filesystems have
both "extended attributes" (i.e., an atomic set/get facility for small
metadata items) and "sub-files".  Of course, as soon as sub-files
start having permissions and access controls associated with them,
then files with subfiles start looking an awful lot like a directory
with a default file if the directory is opened as a file instead of a
directory.  NTFSv5 has both facilities, for example.

The two provide different semantics, and can have very different
performance implications.  If it weren't too late, I'd argue that
NFSv4 NAMED_ATTRIBUTES should be renamed to something less confusing,
and that adding an EXTENDED_ATTRIBUTES extension which has an atomic
set/get facility would be a good thing.

						- Ted

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Thu, 16 Dec 2004 19:31:08 -0800

> Theodore Ts'o
> Sent: Thursday, December 16, 2004 6:57 PM
> To: Gordon Waidhofer
> Cc: J. Bruce Fields; [email-masked]; Halevy, Benny; [email-masked];
> [email-masked]
> Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
> 
> 
> metadata items) and "sub-files".

I can't. But we can agree to disagree.

> Of course, as soon as sub-files
> directory.

That is a fair description of the Solaris mechanism (extended
attributes that should be called subfiles).

> NTFSv5 has both facilities, for example.

Can you cite a reference? URL? This is important
and I've not tripped across anything truly helpful
about where NTFS may be going.

> NFSv4 NAMED_ATTRIBUTES should be renamed to something less confusing,

Subfiles?

> set/get facility would be a good thing.

Ya. That's where we disagree. Attributes require rigorous
definition, XDR encoding, NFSv4 attribute number assignment,
tar/pax name, canonical text definitions, etc, etc, etc.
You can't throw an "attribute" over the wire opaquely.
The problems start with byte order, and then it gets complicated.

An "attribute" is meaningful to the file system, operating
system, and application levels. Data is opaque and meaningful
to only the application level.

There is no such thing as an opaque attribute.

> 						- Ted

Indeed, hashing out the star-to-steer-by file model is
a prerequisite to defining things like NFSV4_READ_NAMED_ATTRIBUTE
permission bits, and the like.

There is no star-to-steer-by file model at this time.

Regards,
	-gww

---

From: David Robinson <[email-masked]>
Date: Fri, 17 Dec 2004 10:53:27 -0600

> through get/set style interface.

There are a couple different issues with trying to
map the Solaris "subfile" extended attributes to
NFSv4 and mapping Linux get/setxattr. From the
protocol perspective we can layer a getxattr
on to NFSv4 with a pretty straight forward compound:

{PUTFH ffh, OPENATTR, LOOKUP "foo_attr", READ 0,4096}

and a setxattr is the obvious use of WRITE. A smart server
could easily optimize this to whatever underlying
interfaces they have.

So the syntax we have over the wire are probably good enough.

The interesting part we need to figure out is if we can
effectively map the common attr model semantics reasonable?

The generality of subfiles provides a lot of flexibility
which we generally would not want to restrict. But when
trying to map the simplier getxattr we will need to define
some convention, otherwise we will get multiple similar but
incompatable implementations. Bruce's example of 3 servers
is exactly to the point.

When it comes to interpretation of named attributes,
the early concensus was that the WG didn't know enough
to feel like they could adequately define a proper set.
I think the biggest error we made was to not define
a mechanism to allow interpreted named attributes to
be specified.  An obvious approach would be to reserve
a 5 byte leading prefix such as the stock symbol approach
many interfaces use, with the special prefix "IETF:"
indicating it is standard. As to encoding, a
published definition is a necessity as XDR is not
self-describing and I would not like to open the door
to one of the ASN.1 families of encodings. [Sorry Nico]

So I think we can work within what we have today, but
create an RFC to more rigorously define semantics for the
interesting cases like getxattr.

	-David

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Fri, 17 Dec 2004 10:11:39 -0800

> David Robinson
> Sent: Friday, December 17, 2004 8:53 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

The Solaris mechanism (why is it called extended attribute?)
isn't just implemented as subfiles, it *IS* subfiles.
The NFSv4 Named Attributes are used to access them, as
will be NT streams (subfiles).

Sure, it's possible to do back flips and wraps
Linux/BSD style Extended Attributes so they can
be accessed by NFSv4 Named Attributes. It is
possible. I'm saying it isn't a good idea.

Indeed, I think it is a remarkably bad idea.

> {PUTFH ffh, OPENATTR, LOOKUP "foo_attr", READ 0,4096}

Now, do it one byte at a time.
> could easily optimize this to whatever underlying

Now, do it one byte at a time. As I said, can't chown(2)
using 8 unordered one byte writes. Can't change a POSIX
ACL doing 1000+ unordered one byte writes.

OK. It is possible. Who's going to do it first? :)

Now, that will seem a weak argument if you think
of Named Attributes as opaque data.

> incompatable implementations. Bruce's example of 3 servers

Convention: don't do it.
 
> to one of the ASN.1 families of encodings. [Sorry Nico]

That's exactly why there is no such thing as an
opaque attribute. Wow. I couldn't possible have
come up with anything scarier. That idea, I hope,
goes a long way to supporting my point as a devil's
advocate position.

Y'all, the term "attribute" is getting diluted
because some want to hold onto the idea of "opaque
attributes". It is becoming necessary to decorate
the noun "attribute" with terms to help us know
what we are talking about: "opaque", "interpretted",
"system", "user". Pretty soon, the word attribute
won't mean anything. This course leads to "opaque
uninterpretted unsystem attributes". That wouldn't
be helpful. If it's opaque, it's an unattribute. :)

Opaque stuff goes in files and subfiles.

"Attributes" are meaningful to all levels and require
rigorous definition (tar/pax, XDR, etc, etc).

Attribute or DATA. Period. This, too me, is helpful
to our collective endeavor.

Much preferable to DATA and $Adjective ATTRIBUTE.

I may be saying all this in my own way.
But I'm not the first to say that the Extended
Attribute mechanisms (OS/2, Linux, FreeBSD, etc, etc)
are for true attributes and never intended as
poor man's subfiles (i.e. opaque, application data).

> interesting cases like getxattr.

The RFC is the NFSv4 spec. The semantics are
defined by adding XDRs and attribute numbers.
It's what makes NFSv4 extensible.

Regards,
	-gww