Subject: Re: [nfsv4] Named attributes and getxattr (fwd)

From: Robert Watson <[email-masked]>
Date: Tue, 15 Nov 2005 20:32:06 +0000 (GMT)

(My original post seems to have been waylaid in the moderation queue, so 
this is a resend)

On Wed, 9 Nov 2005, David Robinson wrote:

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

FWIW, the FreeBSD extended attribute API (also now available in OpenBSD, but I 
think maybe not NetBSD), is similar to the Linux API.  We introduced extended 
attributes in 1999, and provide similar atomic operations based on the 
following user space APIs:

      ssize_t
      extattr_get_fd(int fd, int attrnamespace, const char *attrname,
          void *data, size_t nbytes);

      int
      extattr_set_fd(int fd, int attrnamespace, const char *attrname,
          const void *data, size_t nbytes);

      int
      extattr_delete_fd(int fd, int attrnamespace, const char *attrname);

      ssize_t
      extattr_list_fd(int fd, int attrnamespace, void *data, size_t nbytes);

Variations are present that operate on files by path, and by path without 
following symlinks for the last segment (so as to operate on symlinks). These 
operations provide atomic read and replacement (including truncation to the new 
data size on write).

Extended attributes exist in two name spaces, as they are based on the IRIX 
extended attribute model: system, and user.  The system name space is used for 
things like MAC labels, access control lists, capability masks, file checksums, 
and so on.  The user name space is available to applications.  Both name spaces 
are unstructured, although names often contain '.'s in practice (i.e., 
posix1e.acl, posix1e.acl_default).  User attributes are protected based on the 
permissions of the file; system attributes are writable only with privilege, 
and are generally consumed internally to the kernel (although there are 
exceptions, such as the pre-generation of MD5 checksums written directly to 
system EAs by a user app).

As an FYI, we actually offer somewhat more sophisticated semantics in-kernel 
for extended attributes, including the notion of EA transactions for a 
particular vnode based on an open/operation*/close sequence protected by a 
vnode lock.  This permits cooperating security policies to offer atomicty (and, 
in fact, atomicity in the presence of system failure) in the setting of labels 
across policies.  We do not expose these EA semantics in user space, as we felt 
it was unlikely all file systems would be able to offer these semantics, and 
how to offer the semantics without opening up races or new locking primitives 
seemed difficult.  As the EA facility is intended to provide storage for file 
meta-data, there are strict constraints on the size of extended attributes -- 
on the order of 16k - 64k depending on file system layout.

While the APIs for extended attributes vary across {darwin, linux, freebsd, 
openbsd, irix, ...}, the semantics are actually relatively consistent: they are 
primarily about setting meta-data on files, and are not fully featured file 
fork mechanisms.  My preference is that the two mechanisms not be conflated. 
While it is true that these EA systems can be represented as a subset of file 
forks, significant differences in permission models and semantics are present, 
and could result in poor application behavior, especially in the presence of 
power-loss or network partitioning.  I have particular concerns about what 
happens if applications begin to rely on the availability of a file stream 
mechanism, such as is present in NTFS and UDF, and try to use that facility, 
finding that the backing store is a freebsd/linux/...-style EA mechanism.  The 
result will be pretty non-functional, suggesting strongly that mapping a 
portable stream abstraction into meta-data extended attributes won't provide 
improved portability or application behavior.  Implementors on these systems 
may well find that they want to export native file system streams using the 
NFSv4 extended attribute mechanism, not meta-data extended attributes, in order 
to provide the matching semantics.

My conclusion has been that although NFSv4 EAs and local file system EAs on 
UNIX share a name, there is really little correspondence between their 
semantics and intended use.  UNIX vendors may more accurately think of NFSv4 
EAs as file forks or streams, and will probably want to separately implement 
those facilities in order to provide NFSv4 extended attributes.

Robert N M Watson

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