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]