Support for File System Extended Attributes in NFSv4
draft-naik-nfsv4-xattrs-00

NFSv4 Working Group                                              M. Naik
Internet Draft                                                  M. Eshel
Intended Status: Standards Track                             IBM Almaden
Expires: August 10, 2014                                February 6, 2014

          Support for File System Extended Attributes in NFSv4
                       draft-naik-nfsv4-xattrs-00

Abstract

   This document proposes extensions to existing NFSv4 operations to
   allow file extended attributes (here forth also referred to as
   xattrs) to be manipulated in the protocol. An xattr is a file system
   feature that allows opaque metadata, not interpreted by the file
   system, to be associated with files and directories and are supported
   by many modern file systems. New file attributes are proposed to
   allow clients to query the server for xattr support, and get and set
   xattrs on file system objects.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.
 

Naik, et al.            Expires August 10, 2014                 [Page 1]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Namespaces and Uses . . . . . . . . . . . . . . . . . . . . . .  3
   3  Differences with Named Attributes . . . . . . . . . . . . . . .  4
   4  Protocol Enhancements . . . . . . . . . . . . . . . . . . . . .  5
     4.1  New Attributes  . . . . . . . . . . . . . . . . . . . . . .  5
     4.2  Attribute Definitions . . . . . . . . . . . . . . . . . . .  5
       4.2.1  Attribute 82: xattr_support . . . . . . . . . . . . . .  5
       4.2.2  Attribute 83: maxxattrsize  . . . . . . . . . . . . . .  5
       4.2.3  Attribute 84: xattrsize . . . . . . . . . . . . . . . .  6
       4.2.4  Attribute 85: xattrs  . . . . . . . . . . . . . . . . .  6
       4.2.5  Attribute 86: xattrnames  . . . . . . . . . . . . . . .  6
     4.3  Extensions to ACE Access Mask Attributes  . . . . . . . . .  6
     4.4  Caching . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5  Issues and Alternatives . . . . . . . . . . . . . . . . . . . .  7
     5.1  New Operations - GETXATTR, SETXATTR . . . . . . . . . . . .  7
     5.2  New Operations - GETATTR_PLUS, SETATTR_PLUS . . . . . . . .  8
   6  Related Work  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7  Security Considerations . . . . . . . . . . . . . . . . . . . .  8
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1  Normative References  . . . . . . . . . . . . . . . . . . .  9
     9.2  Informative References  . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

 

Naik, et al.            Expires August 10, 2014                 [Page 2]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

1  Introduction

   Extended attributes are a means to associate opaque metadata with
   file system objects, typically organized in (name, value) pairs. They
   are especially useful when they add information that is not, or
   cannot be, present in the associated object itself. All major
   operating systems provide various flavors of extended attributes.
   Many user space tools allow xattrs to be included in attributes that
   need to be preserved when objects are updated, moved or copied.

   Extended attributes have long been considered unsuitable for
   portability because they are inadequately defined and not documented
   by any standard (such as POSIX). Applications that use or share them
   need to agree on their format. However, evidence shows that xattrs
   are widely deployed and their support in disk-based file systems is
   fairly universal.

   There are no clear indications on how xattrs can be mapped to any
   existing recommended or optional file attributes defined in
   [RFC5661]; thereby most NFS implementations ignore application-
   specified xattrs. This results in data loss if one copies, over the
   NFS protocol, a file with xattrs from one file system to another that
   also supports xattrs. 

   There appears to be relatively strong interest in the community in
   exposing xattrs over NFS despite the shortcomings.

   This document discusses why the current NFSv4 named attributes as
   currently standardized in [RFC5661], are unsuitable for representing
   xattrs, and proposes alternate language, adjustment and protocol
   mechanisms to support them.

1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   In this document, these words will appear with that interpretation  
   only when in ALL CAPS. Lower case uses of these words are not to be  
    interpreted as carrying RFC-2119 significance.

2  Namespaces and Uses

   Operating systems may define multiple "namespaces" in which xattrs
   can be set, but only application-level xattrs that are defined in the
   "user" namespace can be considered interoperable across platforms and
   vendor implementations. (For example, Linux defines "security",
 

Naik, et al.            Expires August 10, 2014                 [Page 3]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

   "system", "trusted" and "user" namespaces. The first three are
   specific to Linux [1]). As such, this document strongly suggests only
   allowing user namespace xattrs to be supported. It is recommended
   that at least one application-specific namespace be used before the
   attribute, to avoid conflicting use of attributes. Additional text
   may be required to restrict the allowed namespaces to user-managed
   metadata only, in order to prevent the development of non-
   interoperable implementations.

   Examples of application-specific xattrs include storing metadata that
   tracks what application created the file, a tag to indicate when the
   file was last verified by a data integrity scrubber, or a tag to hold
   a checksum/crypto hash of the file contents along with the date of
   that signature. Xattrs can also be used for decorations or
   annotations. For example, a file downloaded from a web server can be
   tagged with the URL, which can be convenient if its source has to be
   determined in the future. Likewise, an email attachment can when
   saved be tagged with the message-id of the email. This will make it
   possible to trace the original message. Xattrs can be retrieved and
   set through system calls or shell commands and generally supported by
   user-space tools that preserve other file attributes.

3  Differences with Named Attributes

   [RFC5661] defines named attributes as opaque byte streams that are
   associated with a directory or file and referred to by a string name.
   Named attributes are intended to be used by client applications as a
   method to associate application-specific data with a regular file or
   directory. In that sense, xattrs are similar in concept and use to
   named attributes, but there are subtle differences.

   File systems typically define xattrs operations such as "get" and
   "set" as being atomic. Subsequently, xattrs presumably have size
   limits ranging from a few bytes to several kilobytes, although this
   is not universally defined. Named attributes, on the other hand, are
   unbounded data streams and do not impose atomicity requirements. 

   Individual named attributes are analogous to files, and caching of
   the data for these needs to be handled just as data caching is for
   ordinary files following close-to-open semantics. Xattrs, on the
   other hand, impose caching requirements like other file attributes.

   Named attributes and xattrs have different semantics and belong to
   disjoint namespaces. As a result, mapping one to another is, at best,
   a compromise. 

   While it should be possible to write guidance about how a client can
   use the named attribute mechanism to act like xattrs, such as carving
 

Naik, et al.            Expires August 10, 2014                 [Page 4]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

   out some namespace and specifying locking primitives, this is
   problematic.  A client application trying to use xattrs through named
   attributes with a server that supported xattrs directly would get a
   lower level of service, and could fail to cooperate on a local
   application running on the server unless a shim layer was also
   implemented on the server side. File systems that already implement
   xattrs and named attributes natively would need additional guidance
   such as reserving named attribute namespace specifically for
   implementation purposes.

4  Protocol Enhancements

   This section proposes extensions to the NFSv4 protocol operations to
   allow xattrs to be queried and set by clients. New attributes are
   proposed to bitmap4 data type to allow xattrs to be queried and set.
   This follows the guidelines specified in [RFC5661] with respect to
   minor versioning.

4.1  New Attributes

   The following RECOMMENDED attributes are proposed. A client can query
   the server to determine if xattrs are supported and the maximum size
   of the xattrs that are allowed for a file system object. GETATTR and
   SETATTR can be used to query and set xattrs on an object.

   A client may ask for any of these attributes to be returned by
   setting a bit in the GETATTR request but MUST handle the case where
   the server does not return them.  A client may ask for the set of
   attributes the server supports and SHOULD NOT request attributes the
   server does not support.

   +------------------+----+-------------------+-----+----------------+
   |Name              | Id | Data Type         | Acc | Defined in     |
   +------------------+----+-------------------+-----+----------------+
   | xattr_support    | 82 | Boolean           | R   | Section 4.2.1  |
   | maxxattrsize     | 83 | uint32_t          | R   | Section 4.2.2  |
   | xattrsize        | 84 | uint32_t          | R   | Section 4.2.3  |
   | xattrs           | 85 | xattr4<>          | R W | Section 4.2.4  |
   | xattrnames       | 86 | xattrname4<>      | R   | Section 4.2.5  |
   +------------------+----+-------------------+-----+----------------+

4.2  Attribute Definitions

4.2.1  Attribute 82: xattr_support

   TRUE, if the object's file system supports extended attributes.

4.2.2  Attribute 83: maxxattrsize
 

Naik, et al.            Expires August 10, 2014                 [Page 5]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

   Maximum size in bytes of all the extended attributes per object that
   the object's file system supports.

4.2.3  Attribute 84: xattrsize

   The total size of all the extended attributes of this object in
   bytes.

4.2.4  Attribute 85: xattrs

   The xattrs attribute contains an array of extended attributes that
   are associated with the file system object. Although the client can
   get and set xattrs, the server is responsible for using the xattrs
   for its own purposes. Any regular file or directory may have xattrs,
   each consisting of a name and associated data. Similar to ACLs, the
   client can use the OPEN or ACCESS operations to check access without
   modifying or reading data or metadata. For SETATTR operation, if the
   associated xattrvalue4 has a length of zero, the corresponding xattr
   is to be deleted, if it exists. Specific names of attributes will not
   be controlled by this document or other IETF Standards Track
   documents.

   The NFS xattr structure is defined as follows:

        typedef utf8str_cis     xattrname4;
        typedef opaque          xattrvalue4<>;

        struct xattr4 {
                xattrname4     xa_name;
                xattrvalue4    xa_value;
        };

4.2.5  Attribute 86: xattrnames

   The xattrnames is similar to xattrs attribute, except that it only
   returns the names of the xattrs for the file system object without
   the values. Each xattr is a tuple of the form (name, value).
   xattrname4 is a UTF-8 string denoting the xattr name, xattrvalue4 is
   a variable length string that identifies the values of a specified
   xattr. The NFS client or server must not interpret the value.

4.3  Extensions to ACE Access Mask Attributes

   Two new bitmask constants are proposed for the access mask field:

         const ACE4_READ_XATTRS          = 0x00200000;
         const ACE4_WRITE_XATTRS         = 0x00400000;
 

Naik, et al.            Expires August 10, 2014                 [Page 6]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

   Permission to read and write the extended attributes of a file. The
   affected operations are GETATTR and SETATTR respectively. No
   additional granularity of control is implied by these constants for
   server implementations.

4.4  Caching

   Similar to other attributes like ACLs, clients may cache xattrs
   obtained from the server and use them to avoid subsequent GETATTR
   requests. Similarly, such caching is write through in that
   modification to file attributes is always done by means of requests
   to the server and should not be done locally and should not be
   cached. Due to the relative infrequency of xattr updates, it is
   suggested that all changes be propagated synchronously.

5  Issues and Alternatives

   The proposed bitmap changes treat the object xattrs as a single
   attribute, allowing them to be read and written in a single GETATTR
   or SETATTR request respectively, similar to other metadata attributes
   (such as ACLs). In reality, most file systems allow disparate
   metadata to be associated with an object through xattrs, where
   combining them into a single entity is unwieldy. For example,
   obtaining the value of a single xattr using the bitmap would require
   a client implementation to read all the xattrs of the file and find a
   match for the one requested. Similarly, replacing or deleting a
   single xattr while keeping the others intact would require a client
   to read the xattrs first, replacing the existing list with a modified
   list that excludes the one to be deleted, and writing out the
   remaining xattrs. 

5.1  New Operations - GETXATTR, SETXATTR

   An alternative to modifying the existing attribute bitmap is to
   introduce two separate operations, such as GETXATTR and SETXATTR,
   that allow querying and setting of xattrs. This has the advantage of
   allowing new functionality that is otherwise difficult to support
   with existing operations. For example, GETXATTR could allow listing
   all the xattrs names, names with values, or querying the value of a
   single name. SETXATTR could allow deleting a single xattr or
   replacing a few without modifying the rest. 

   The disadvantage of defining entirely new operations is with
   specifying consistency semantics with respect to existing operations.
   For example, modifying a file's xattrs also affects its time_metadata
   attribute. Obtaining these through separate RPC operations (GETATTR
   and GETXATTR) would violate cache consistency semantics.

 

Naik, et al.            Expires August 10, 2014                 [Page 7]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

5.2  New Operations - GETATTR_PLUS, SETATTR_PLUS

   Another option is to define new operations, GETATTR_PLUS and
   SETATTR_PLUS, that support all the features of the existing NFSv4
   GETATTR and SETATTR operations, but allow more information to be
   specified to the server, and add information to the format of the
   response, in addition to attribute bitmap.

6  Related Work

   Extended attributes are supported by many file systems.

   In Linux, the ext2, ext3, ext4, JFS, ReiserFS, XFS, Btrfs and OCFS2
   file systems support extended attributes. The getfattr and setfattr
   utilities can be used to retrieve and set xattrs. The names of the
   extended attributes must be prefixed by the name of the category and
   a dot; hence these categories are generally qualified as name spaces.
   Currently, four namespaces exist: user, trusted, security and system.
   Recommendations on how they should be used are published by
   freedesktop.org [1].

   In FreeBSD, the UFS1 and UFS2 file systems (5.0 and later) and XFS
   (8.0 and later) support extended attributes in two namespaces - user
   and system. The associated utilities are getextattr, lsextattr,
   rmextattr, and setextattr.

   Solaris (9 and later) allows files to have extended attributes, but
   implements them as "forks". 

   On Windows NT, limited-length extended attributes are supported by
   FAT, HPFS, and NTFS. Additionally, NTFS can support infinite-length
   extended attributes in the form of Alternate Data Streams (ADS), a
   type of resource fork.

   Mac OS X 10.4 and later support extended attributes through open name
   spaces enabled through a mount option.

7  Security Considerations

   The additions to the NFS protocol for supporting extended attributes
   do not alter the security considerations of the NFSv4.1 protocol
   [RFC5661].

8  IANA Considerations

   There are no IANA considerations in this document.  All NFSv4.1 IANA
   considerations are covered in [RFC5661].
 

Naik, et al.            Expires August 10, 2014                 [Page 8]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

9  References

9.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5661]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              Protocol", RFC 5661, January 2010.

   [RFC5662]  Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
              "Network File System (NFS) Version 4 Minor Version 1
              External Data Representation Standard (XDR) Description",
              RFC 5662, January 2010.

9.2  Informative References

   [1]        http://www.freedesktop.org/wiki/CommonExtendedAttributes,
   "Guidelines for extended attributes".

 

Naik, et al.            Expires August 10, 2014                 [Page 9]
Internet Draft        Extended Attributes in NFSv4      February 6, 2014

Authors' Addresses

   Manoj Naik
   IBM Almaden
   650 Harry Rd
   San Jose, CA 95120

   Phone: +1 408-927-1707
   Email: mnaik@us.ibm.com

   Marc Eshel
   IBM Almaden
   650 Harry Rd
   San Jose, CA 95120

   Phone: +1 408-927-1894
   Email: eshel@us.ibm.com

Naik, et al.            Expires August 10, 2014                [Page 10]