Subject: [nfsv4] Named attributes and getxattr

From: David Robinson <[email-masked]>
Date: Wed, 9 Nov 2005 17:32:22 -0600

In a recent thread of discussion (ACLs) the topic
of the common Linux APIs of getxattr/setxattr/listxattr
and friends.

This API is clearly a subset of the named attributes
used within NFSv4, one that is mostly flat.  But as a subset
there should be some common mapping.

In RFC3530 section 17.1, the protocol clearly states that
it does not impose any structure on the named attribute namespace.
But looking at the getxattr implementations, many have defined
a "prefix" string to distinguish between different classes
of extended attributes.  The common ones that I found
were "user.*", "system.*", and "trusted.*". But others
may also exist.

The obvious mapping is to simply translate "prefix.attrname"
into a similarly named attribute in the root of the
attribute tree.

An alternative approach is to place the prefix as a subdirectory
with each attribute as a file within those directories.  An
interesting side effect of this is that it could allow
setting restrictive permissions on the subdirectory to
limit access to "system" or other classes of attributes.

How are people implementing mapping this API to NFSv4?

It would seem to be in the community's best interest to
define a standard mapping for interoperability?

Is there a preferred structure? Flat versus hierarchy?

What is the set of common "prefix"es that we would like
to reserve?

Are there any mappings between a "system" ACL attribute
and the existing NFSv4 ACLs? Or other well known system
attributes?

Do we want to reserve other prefixes or directory names
for vendor specific attributes? SUNW.*, IBM.*, NTAP.*?

Or do we want to maintain a free for all?

	-David

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 9 Nov 2005 18:44:41 -0500

> there should be some common mapping.

Does there have to be?

> limit access to "system" or other classes of attributes.

Another alternative would be to keep the two namespaces--extended
attributes and named attributes--entirely separate.

On Linux that would require an entirely new interface for NFSv4 named
attributes.  But there seem to be some other people interested in that
sort of "subfile" model, so that's not out of the question.

There are some odd mismatches between extended attributes and NFSv4
named attributes; I'm not convinced they're such a good fit.

> Or do we want to maintain a free for all?

Could we just leave management of the named attribute namespace entirely
up to the user?  From rfc3530:

	"A named attribute is an opaque byte stream that is associated
	with a directory or file and referred to by a string name.
	Named attributes are meant to be used by client applications as
	a method to associate application specific data with a regular
	file or directory."

That suggests to me that the named attributes are meant to be left up to
users and applications, not taken over by the client or server as a way
to export OS-specific interfaces.

--b.

---

From: David Robinson <[email-masked]>
Date: Wed, 9 Nov 2005 19:04:49 -0600

>> there should be some common mapping.

No, but deciding there is no mapping is still a decision.
In the absence of such a decision we are likely to have
vendors doing incompatible ad hoc things.

> attributes and named attributes--entirely separate.

That would be a reasonable alternative, but it then begs the
question of providing a mechanism to get/set/list extended
attributes over the wire. An new OPENXATTR with the same semantics
as OPENATTR but an alternative namespace? A simpler
flat GETXATTR/SETXATTR/LISTXATTR?

> to export OS-specific interfaces.

That is one interpretation that seems to fit. But in the absence of
a mechanism that provides a generally extensible extended attribute
model, there is strong attraction for a vendor to "just use it".
While it can be argued that BazCo Inc. using the BZCO prefix
or subdirectory is not fully within the spirit of RFC3530,
the odds of conflict with a real user is so small that I doubt
the market would stop it. It is clearly better than picking some
arbitrary integer.

If I recall the original discussion, there were some opinions that it
could be used for system or vendor specific attributes. A major
detractor from defining a namespace was the lack of a
real world example namespace or a desire at the time to define one.

But also note, that RFC3530 section 17.1 also states that portions
of the namespace can be registered with IANA and published
through an informational RFC:

    Even though the name space is not specifically controlled to prevent
    collisions, an IANA registry has been created for the registration of
    NFS version 4 named attributes.  Registration will be achieved
    through the publication of an Informational RFC and will require not
    only the name of the attribute but the syntax and semantics of the
    named attribute contents; the intent is to promote interoperability
    where common interests exist.  While application developers are
    allowed to define and use attributes as needed, they are encouraged
    to register the attributes with IANA.

So an argument could be made that a "Linux" system is an application
of the protocol, and this is a proposal to reserve the named
attributes "system", "user", and "trusted" with IANA and published
in an Informational RFC as a suggested mapping for the getxattr/setxattr
interfaces. It would not prevent some other application from
colliding, but it is at least a public declaration of intent.

I have preferences to used named attrs, but I am not opposed
to new OPs or other techniques, but I
do think it would be useful to come to a common consensus on how
getxattr/setxattr get reflected on to the network. Even if it is
just an Informational RFC telling vendors to not use named attrs.

	-David

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 09 Nov 2005 22:26:13 -0500

> flat GETXATTR/SETXATTR/LISTXATTR?

The only argument I have seen so far for exporting the xattr attributes
comes from the SELinux people, who want to use them to export security
contexts (via a dedicated "system.context" channel). However they _only_
want to do this for NFS, and not for local filesystems, so perhaps the
right way to resolve that would be to set up a dedicated operation.

Most of the other "system.*" xattrs tend to be ioctl-like local
operations (for instance, we export our ACLs to userland via the xattrs
"system.posix_acl_access", "system.posix_acl_default", and
"system.nfs4_acl"). I can't imagine wanting to export those via NFS.

I'm not aware of anybody actually using the "user.*" xattr interface for
anything useful at the moment, either. Perhaps that will change,
though...

Cheers,
  Trond