summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8276.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8276.txt')
-rw-r--r--doc/rfc/rfc8276.txt1571
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc8276.txt b/doc/rfc/rfc8276.txt
new file mode 100644
index 0000000..9e694db
--- /dev/null
+++ b/doc/rfc/rfc8276.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Naik
+Request for Comments: 8276 Nutanix
+Category: Standards Track M. Eshel
+ISSN: 2070-1721 IBM Almaden
+ December 2017
+
+
+ File System Extended Attributes in NFSv4
+
+Abstract
+
+ This document describes an optional feature extending the NFSv4
+ protocol. This feature allows extended attributes (hereinafter also
+ referred to as xattrs) to be interrogated and manipulated using NFSv4
+ clients. Xattrs are provided by a file system to associate opaque
+ metadata, not interpreted by the file system, with files and
+ directories. Such support is present in many modern local file
+ systems. New file attributes are provided to allow clients to query
+ the server for xattr support, with that support consisting of new
+ operations to get and set xattrs on file system objects.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8276.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 1]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 2]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Uses of Extended Attributes . . . . . . . . . . . . . . . . . 5
+ 3. Functional Gaps Due to Lack of NFSv4 Extended Attribute
+ Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. File System Support for Extended Attributes . . . . . . . . . 6
+ 5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. Relationship with Named Attributes . . . . . . . . . . . . . 7
+ 7. XDR Description . . . . . . . . . . . . . . . . . . . . . . . 8
+ 7.1. Code Components Licensing Notice . . . . . . . . . . . . 9
+ 7.2. XDR for Xattr Extension . . . . . . . . . . . . . . . . . 11
+ 8. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 11
+ 8.1. New Definitions . . . . . . . . . . . . . . . . . . . . . 11
+ 8.2. New Attribute . . . . . . . . . . . . . . . . . . . . . . 12
+ 8.2.1. xattr_support . . . . . . . . . . . . . . . . . . . . 12
+ 8.3. New Error Definitions . . . . . . . . . . . . . . . . . . 12
+ 8.3.1. NFS4ERR_NOXATTR (Error Code 10095) . . . . . . . . . 12
+ 8.3.2. NFS4ERR_XATTR2BIG (Error Code 10096) . . . . . . . . 13
+ 8.4. New Operations . . . . . . . . . . . . . . . . . . . . . 13
+ 8.4.1. GETXATTR - Get an Extended Attribute of a File . . . 14
+ 8.4.2. SETXATTR - Set an Extended Attribute of a File . . . 15
+ 8.4.3. LISTXATTRS - List Extended Attributes of a File . . . 17
+ 8.4.4. REMOVEXATTR - Remove an Extended Attribute of a File 18
+ 8.4.5. Valid Errors . . . . . . . . . . . . . . . . . . . . 19
+ 8.5. Modifications to Existing Operations . . . . . . . . . . 21
+ 8.6. Numeric Values Assigned to Protocol Extensions . . . . . 22
+ 8.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 8.8. Xattrs and File Locking . . . . . . . . . . . . . . . . . 25
+ 8.9. pNFS Considerations . . . . . . . . . . . . . . . . . . . 25
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 27
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+
+
+
+
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 3]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+1. Introduction
+
+ Extended attributes, also called xattrs, are a means to associate
+ opaque metadata with file system objects, organized as key/value
+ pairs. They are especially useful when they add information that is
+ not, or cannot be, present in the associated object itself. User-
+ space applications can arbitrarily create, interrogate, and modify
+ the key/value pairs.
+
+ Extended attributes are file system agnostic; applications use an
+ interface not specific to any file system to manipulate them.
+ Applications are not concerned about how the key/value pairs are
+ stored internally within the underlying file system. All major
+ operating systems provide facilities to access and modify extended
+ attributes. Many user-space tools allow xattrs to be included
+ together with regular attributes that need to be preserved when
+ objects are updated, moved, or copied.
+
+ Extended attributes have not previously been included within the
+ NFSv4 specification. Some issues that need to be addressed in order
+ to be included are that, as with named attributes, some aspects of
+ the handling of xattrs are not precisely defined and xattrs are not
+ formally documented by any standard such as POSIX [POSIX].
+ Nevertheless, it appears that xattrs are widely deployed, and their
+ support in modern disk-based file systems is nearly universal.
+
+ There is no current specification of how xattrs could be mapped to
+ any existing file attributes defined in the NFSv4 protocol [RFC5661]
+ [RFC7530] [RFC7862]. As a result, most NFSv4 client implementations
+ ignore application-specified xattrs. This state of affairs results
+ in data loss if one copies, over the NFSv4 protocol, a file with
+ xattrs from one file system to another that also supports xattrs.
+
+ There is thus a need to provide a means by which such data loss can
+ be avoided. This will involve exposing xattrs within the NFSv4
+ protocol, despite the lack of completely compatible file system
+ implementations.
+
+ This document discusses (in Section 5) the reasons that NFSv4-named
+ attributes, as currently standardized in [RFC5661], are unsuitable
+ for representing xattrs. Instead, it describes a separate protocol
+ mechanism to support xattrs. As a consequence, xattrs and named
+ attributes will both be OPTIONAL features with servers free to
+ support either, both, or neither.
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 4]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. Uses of Extended Attributes
+
+ Applications can store tracking information in extended attributes.
+ Examples include storing metadata identifying the application that
+ 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, when saved, can be tagged with the
+ message-id of the email, making it possible to trace the original
+ message.
+
+ Applications may need to behave differently when handling files of
+ varying types. For example, file managers, such as GNOMEs, offer
+ unique icons, different click behavior, and special lists of
+ operations to perform depending on the file format. This can be
+ achieved by looking at the file extension (Windows), or the type can
+ be interpreted by inspecting it (Unix MIME type). Some file managers
+ generate this information on the fly; others generate the information
+ once and then cache it. Those that cache the information tend to put
+ it in a custom database. The file manager must work to keep this
+ database in sync with the files, which can change without the file
+ manager's knowledge. A better approach is to dispense with the
+ custom database and store such metadata in extended attributes. This
+ is easier to maintain, provides faster access, and is readily
+ accessible by applications [Love].
+
+3. Functional Gaps Due to Lack of NFSv4 Extended Attribute Support
+
+ In addition to the prospect of data loss (discussed in Section 1)
+ that arises from use of xattrs on local file systems, application use
+ of xattrs poses further difficulties given the current lack of xattr
+ support within NFSv4. As a result, certain applications may not be
+ supported by NFSv4 or may be supported in an unsatisfactory way.
+ Some examples are discussed below.
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 5]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ Swift, the OpenStack distributed object store, uses xattrs to store
+ an object's metadata along with all the data together in one file.
+ Swift-on-File [Swift] transfers the responsibility of maintaining
+ object durability and availability to the underlying file system. At
+ the time of writing, this requires a native file system client to
+ mount the volumes. Xattr support in NFSv4 would open up the
+ possibility of storing and consuming data from other storage systems
+ and facilitate the migration of data between different backend
+ storage systems.
+
+ Baloo, the file indexing and search framework for Key Distribution
+ Exchange (KDE), has moved to storing metadata such as tags, ratings,
+ and comments in file system xattrs instead of a custom database for
+ simplicity. Starting with KDE Plasma 5.1, NFS is no longer supported
+ due to its lack of xattr support [KDE].
+
+4. File System Support for Extended Attributes
+
+ Extended attributes are supported by most modern file systems.
+
+ Some of the file systems that support extended attributes in Linux
+ are as follows: ext3, ext4, JFS, XFS, and Btrfs. 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 namespaces. Currently, four namespaces exist: user, trusted,
+ security, and system [Linux]. Recommendations on how they should be
+ used have been published [freedesktop].
+
+ FreeBSD supports extended attributes in two universal namespaces --
+ user and system -- although individual file systems are allowed to
+ implement additional namespaces [FreeBSD].
+
+ Some file systems have facilities that are capable of storing both
+ extended attributes and named attributes. For discussion regarding
+ the relationship between these features, see Section 5. Solaris 9
+ and later provide file "forks", logically represented as files within
+ a hidden directory that is associated with the target file [fsattr].
+ In the New Technology File System (NTFS), extended attributes may be
+ stored within "file streams" [NTFS].
+
+ Xattrs can be retrieved and set through system calls or shell
+ commands and are generally supported by user-space tools that
+ preserve other file attributes. For example, the "rsync" remote copy
+ program will correctly preserve user-extended attributes between
+ Linux/ext4 and OSX/hfs by stripping off the Linux-specific "user."
+ prefix.
+
+
+
+
+Naik & Eshel Standards Track [Page 6]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+5. Namespaces
+
+ Operating systems may define multiple "namespaces" in which xattrs
+ can be set. Namespaces are more than organizational classes; the
+ operating system may enforce different access policies and allow
+ different capabilities depending on the namespace. Linux, for
+ example, defines "security", "system", "trusted", and "user"
+ namespaces, the first three being specific to Linux [freedesktop].
+
+ Implementations generally agree on the semantics of a "user"
+ namespace, which allows applications to store arbitrary user
+ attribute data with file system objects. Access to this namespace is
+ controlled via the normal file system attributes. As such, getting
+ and setting xattrs from the user namespace can be considered
+ interoperable across platforms and vendor implementations.
+ Attributes from other namespaces are typically platform specific.
+
+ This document provides support for namespaces related to user-managed
+ metadata only, thus avoiding the need to specify the semantics
+ applicable to particular system-interpreted xattrs. The values of
+ xattrs are considered application data just as the contents of named
+ attributes, files, and symbolic links are. Servers have a
+ responsibility to store whatever value the client specifies and to
+ return it on demand. Xattr keys and values MUST NOT be interpreted
+ by the NFS clients and servers, as such behavior would lead to
+ non-interoperable implementations. If there were a need to specify
+ one or more attributes that servers need to act upon, the appropriate
+ semantics would be specified by adding a new attribute for the
+ purpose as provided for by [RFC5661] and [RFC8178].
+
+6. Relationship with Named Attributes
+
+ [RFC7530] 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. Although this makes xattrs similar in concept and use to
+ named attributes, there are important semantic differences.
+
+ File systems typically define operations to get and set individual
+ xattrs as being atomic, although collectively they may be
+ independent. Xattrs generally have size limits ranging from a few
+ bytes to several kilobytes; the maximum supported size is not
+ universally defined and is usually restricted by the file system.
+ Similar to Access Control Lists (ACLs), the amount of xattr data
+ exchanged between the client and server for get/set operations can be
+ considered to fit in a single COMPOUND request, bounded by the
+
+
+
+
+Naik & Eshel Standards Track [Page 7]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ channel's negotiated maximum size for requests. Named attributes, on
+ the other hand, are unbounded data streams and do not impose
+ atomicity requirements.
+
+ Individual named attributes are analogous to files and are opened and
+ closed just as files are. 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, have caching
+ requirements similar to other file attributes.
+
+ Named attributes and xattrs have different semantics and are treated
+ by applications as belonging to disjoint namespaces. As a result,
+ mapping from one to the other would be, at best, a compromise.
+ Despite these differences, the underlying file system structure used
+ to store named attributes is generally capable of storing xattrs.
+ However, the converse is typically not the case because of the size
+ limits applicable to xattrs.
+
+ While it might be possible to write guidance about how a client can
+ use the named attribute mechanism to act like xattrs, such as by
+ carving out some namespace and specifying locking primitives to
+ enforce atomicity constraints on individual get/set operations, such
+ an approach is sufficiently problematic; thus, it will not be
+ attempted here. 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 the server file system
+ defined its own interoperability constraints. File systems that
+ already implement xattrs and named attributes natively would need
+ additional guidance such as reserving a named attribute namespace
+ specifically for implementation purposes.
+
+7. XDR Description
+
+ This document contains the External Data Representation (XDR)
+ [RFC4506] description of the extended attributes. The XDR
+ description is embedded in this document in a way that makes it
+ simple for the reader to extract into a ready-to-compile form. The
+ reader can feed this document into the following shell script to
+ produce the machine-readable XDR description of extended attributes:
+
+ <CODE BEGINS>
+
+ #! /bin/sh
+ grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'
+
+ <CODE ENDS>
+
+
+
+
+Naik & Eshel Standards Track [Page 8]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ That is, if the above script is stored in a file called "extract.sh",
+ and this document is in a file called "spec.txt", then the reader can
+ do:
+
+ sh extract.sh < spec.txt > xattr_prot.x
+
+ The effect of the script is to remove leading white space from each
+ line, plus a sentinel sequence of "///".
+
+ The initial section of the embedded XDR file header follows.
+ Subsequent XDR descriptions, with the sentinel sequence, are embedded
+ throughout the document.
+
+ Note that the XDR code contained in this document depends on types
+ from the NFSv4.2 nfs4_prot.x file [RFC7863]. This includes both nfs
+ types that end with a 4, such as nfs_cookie4, count4, etc., as well
+ as more-generic types, such as opaque and bool.
+
+ To produce a compilable XDR file, the following procedure is
+ suggested:
+
+ o Extract the file nfs4_prot.x as described in [RFC7863].
+
+ o Extract xattr_prot.x from this document as described above.
+
+ o Apply any changes required for other extensions to be included
+ together with the xattr extension.
+
+ o Perform modifications to nfs4_prot.x as described by comments
+ within xattr_prot.x.
+
+ o Extend the unions nfs_argop4 and nfs_resop4 to include cases for
+ the new operations defined in this document.
+
+ o Combine the XDR files for the base NFSv4.2 protocol and all needed
+ extensions by either concatenating the relevant XDR files or using
+ file inclusion.
+
+7.1. Code Components Licensing Notice
+
+ Both the XDR description and the scripts used for extracting the XDR
+ description are Code Components as described in "Legal Provisions
+ Relating to IETF Documents", Section 4 of [LEGAL]. These Code
+ Components are licensed according to the terms of that document.
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 9]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ <CODE BEGINS>
+
+ /// /*
+ /// * Copyright (c) 2017 IETF Trust and the persons identified
+ /// * as authors of the code. All rights reserved.
+ /// *
+ /// * Redistribution and use in source and binary forms, with
+ /// * or without modification, are permitted provided that the
+ /// * following conditions are met:
+ /// *
+ /// * o Redistributions of source code must retain the above
+ /// * copyright notice, this list of conditions and the
+ /// * following disclaimer.
+ /// *
+ /// * o Redistributions in binary form must reproduce the above
+ /// * copyright notice, this list of conditions and the
+ /// * following disclaimer in the documentation and/or other
+ /// * materials provided with the distribution.
+ /// *
+ /// * o Neither the name of Internet Society, IETF or IETF
+ /// * Trust, nor the names of specific contributors, may be
+ /// * used to endorse or promote products derived from this
+ /// * software without specific prior written permission.
+ /// *
+ /// * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
+ /// * AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
+ /// * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ /// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ /// * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+ /// * EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ /// * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ /// * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ /// * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ /// * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ /// * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ /// * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ /// * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+ /// * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ /// * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ /// *
+ /// * This code was derived from RFC 8276.
+ /// * Please reproduce this note if possible.
+ /// */
+
+ <CODE ENDS>
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 10]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+7.2. XDR for Xattr Extension
+
+ <CODE BEGINS>
+
+ /// /*
+ /// * xattr_prot.x
+ /// */
+
+ /// /*
+ /// * The following includes statements that are for example only.
+ /// * The actual XDR definition files are generated separately
+ /// * and independently and are likely to have a different name.
+ /// * %#include <rpc_prot.x>
+ /// * %#include <nfsv42.x>
+ /// */
+
+ <CODE ENDS>
+
+8. Protocol Extensions
+
+ This section documents extensions to the NFSv4 protocol operations to
+ allow xattrs to be queried and modified by clients. A new attribute
+ is added to allow clients to determine if the file system being
+ accessed provides support for xattrs. New operations are defined to
+ allow xattr keys and values to be queried and set. In addition, the
+ ACCESS operation is extended by adding new mask bits to provide
+ access information relating to xattrs.
+
+ These changes follow applicable guidelines for valid NFSv4 XDR
+ protocol extension, as specified in [RFC8178], and obey the rules for
+ extensions capable of being made without a change in minor version
+ number.
+
+8.1. New Definitions
+
+ <CODE BEGINS>
+
+ /// typedef component4 xattrkey4;
+ /// typedef opaque xattrvalue4<>;
+
+ <CODE ENDS>
+
+ Each xattr is a key/value pair. xattrkey4 is a string denoting the
+ xattr key name and an attrvalue4, which is a variable-length string
+ that identifies the value of the xattr. The handling of xattrkey4
+ with regard to internationalization-related issues is the same as
+ that for NFSv4 file names and named attribute names, as described in
+ [RFC7530]. Any regular file or directory may have a set of extended
+
+
+
+Naik & Eshel Standards Track [Page 11]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ attributes, each consisting of a key and associated value. The NFS
+ client or server MUST NOT interpret the contents of xattrkey4 or
+ xattrvalue4.
+
+8.2. New Attribute
+
+ The per-fs read-only attribute described below may be used to
+ determine if xattrs are supported. Servers need not support this
+ attribute, and some NFSv4.2 servers may be unaware of its existence.
+ Before interrogating this attribute using GETATTR, a client should
+ determine whether it is a supported attribute by interrogating the
+ supported_attrs attribute.
+
+8.2.1. xattr_support
+
+ xattr_support is set to True, if the object's file system supports
+ extended attributes.
+
+ Since xattr_support is not a REQUIRED attribute, the server need not
+ support it. However, a client may reasonably assume that a server
+ (or file system) that does not support the xattr_support attribute
+ does not provide xattr support, and it acts on that basis.
+
+ Note that the protocol does not enforce any limits on the number of
+ keys, the length of a key, the size of a value, or the total size of
+ xattrs that are allowed for a file. The server file system MAY
+ impose additional limits. In addition, a single xattr key or value
+ exchanged between the client and server for get/set operations is
+ limited by the channel's negotiated maximum size for requests and
+ responses.
+
+8.3. New Error Definitions
+
+ <CODE BEGINS>
+
+ /// /* Following lines are to be added to enum nfsstat4 */
+ /// /*
+ /// NFS4ERR_NOXATTR = 10095, /* xattr does not exist */
+ /// NFS4ERR_XATTR2BIG = 10096 /* xattr value is too big */
+ /// */
+
+ <CODE ENDS>
+
+8.3.1. NFS4ERR_NOXATTR (Error Code 10095)
+
+ The specified xattr does not exist or the server is unable to
+ retrieve it.
+
+
+
+
+Naik & Eshel Standards Track [Page 12]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+8.3.2. NFS4ERR_XATTR2BIG (Error Code 10096)
+
+ The size of the xattr value specified as part of a SETXATTR
+ operation, or the collective size of all xattrs of the file resulting
+ from the SETXATTR operation, is bigger than that supported by the
+ underlying file system.
+
+8.4. New Operations
+
+ Applications need to perform the following operations on a given
+ file's extended attributes [Love]:
+
+ o Given a file, return a list of all of the file's assigned extended
+ attribute keys.
+
+ o Given a file and a key, return the corresponding value.
+
+ o Given a file, a key, and a value, assign that value to the key.
+
+ o Given a file and a key, remove that extended attribute from the
+ file.
+
+ In order to meet these requirements, this section introduces four new
+ OPTIONAL operations: GETXATTR, SETXATTR, LISTXATTRS and REMOVEXATTR.
+ These operations are to query, set, list, and remove xattrs,
+ respectively. A server MUST support all four operations when they
+ are directed to a file system that supports the xattr_support
+ attribute and returns TRUE when it is interrogated. For file systems
+ that either do not support the xattr_support attribute or return
+ FALSE when the xattr_support attribute is interrogated, all of the
+ above operations MUST NOT be supported. GETXATTR allows obtaining
+ the value of an xattr key, SETXATTR allows creating or replacing an
+ xattr key with a value, LISTXATTRS enumerates all the xattrs names,
+ and REMOVEXATTR allows deleting a single xattr.
+
+ Note that some server implementations may not be aware of the
+ existence of these operations, thereby a client cannot always expect
+ that issuing one of them will either succeed or return
+ NFS4ERR_NOTSUPP. In some cases, NFS4ERR_OP_ILLEGAL may be returned
+ or the request may encounter an XDR decode error on the server. As a
+ result, clients should only issue these operations after determining
+ that support is present.
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 13]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+8.4.1. GETXATTR - Get an Extended Attribute of a File
+
+8.4.1.1. ARGUMENTS
+
+ <CODE BEGINS>
+
+ /// struct GETXATTR4args {
+ /// /* CURRENT_FH: file */
+ /// xattrkey4 gxa_name;
+ /// };
+
+ <CODE ENDS>
+
+8.4.1.2. RESULTS
+
+ <CODE BEGINS>
+
+ /// union GETXATTR4res switch (nfsstat4 gxr_status) {
+ /// case NFS4_OK:
+ /// xattrvalue4 gxr_value;
+ /// default:
+ /// void;
+ /// };
+
+ <CODE ENDS>
+
+8.4.1.3. DESCRIPTION
+
+ The GETXATTR operation will obtain the value for the given extended
+ attribute key for the file system object specified by the current
+ filehandle.
+
+ The server will fetch the xattr value for the key that the client
+ requests if xattrs are supported by the server for the target file
+ system. If the server does not support xattrs on the target file
+ system, then it MUST NOT return a value and MUST return the
+ NFS4ERR_NOTSUPP error or another error indicating the request was not
+ understood. The server also MUST return NFS4ERR_NOXATTR if it
+ supports xattrs on the target but cannot obtain the requested data.
+ If the xattr value contained in the server response is such as to
+ cause the channel's negotiated maximum response size to be exceeded,
+ then the server MUST return NFS4ERR_REP_TOO_BIG in gxr_status.
+
+8.4.1.4. IMPLEMENTATION
+
+ Clients that have cached an xattr may avoid the need to do a GETXATTR
+ by determining if the change attribute is the same as it was when the
+ xattr was fetched. If the client does not hold a delegation for the
+
+
+
+Naik & Eshel Standards Track [Page 14]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ file in question, it can obtain the change attribute with a GETATTR
+ request and compare that change attribute's value to the change
+ attribute value fetched when the xattr value was obtained. This
+ handling is similar to how a client would revalidate other file
+ attributes such as ACLs.
+
+ When responding to such a GETATTR, the server will, if there is an
+ OPEN_DELEGATE_WRITE delegation held by another client for the file in
+ question, either obtain the actual current value of these attributes
+ from the client holding the delegation by using the CB_GETATTR
+ callback or revoke the delegation. See Section 18.7.4 of [RFC5661]
+ for details.
+
+8.4.2. SETXATTR - Set an Extended Attribute of a File
+
+8.4.2.1. ARGUMENTS
+
+ <CODE BEGINS>
+
+ /// enum setxattr_option4 {
+ /// SETXATTR4_EITHER = 0,
+ /// SETXATTR4_CREATE = 1,
+ /// SETXATTR4_REPLACE = 2
+ /// };
+
+ /// struct SETXATTR4args {
+ /// /* CURRENT_FH: file */
+ /// setxattr_option4 sxa_option;
+ /// xattrkey4 sxa_key;
+ /// xattrvalue4 sxa_value;
+ /// };
+
+ <CODE ENDS>
+
+8.4.2.2. RESULTS
+
+ <CODE BEGINS>
+
+ /// union SETXATTR4res switch (nfsstat4 sxr_status) {
+ /// case NFS4_OK:
+ /// change_info4 sxr_info;
+ /// default:
+ /// void;
+ /// };
+
+ <CODE ENDS>
+
+
+
+
+
+Naik & Eshel Standards Track [Page 15]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+8.4.2.3. DESCRIPTION
+
+ The SETXATTR operation changes one extended attribute of a file
+ system object. The change desired is specified by sxa_option.
+ SETXATTR4_CREATE is used to associate the given value with the given
+ extended attribute key for the file system object specified by the
+ current filehandle. The server MUST return NFS4ERR_EXIST if the
+ attribute key already exists. SETXATTR4_REPLACE is also used to set
+ an xattr, but the server MUST return NFS4ERR_NOXATTR if the attribute
+ key does not exist. By default (SETXATTR4_EITHER), the extended
+ attribute will be created if need be, or its value will be replaced
+ if the attribute exists.
+
+ If the xattr key and value contained in the client request are such
+ that the request would exceed the channel's negotiated maximum
+ request size, then the server MUST return NFS4ERR_REQ_TOO_BIG in
+ sxr_status. If the server file system imposes additional limits on
+ the size of the key name or value, it MAY return NFS4ERR_XATTR2BIG.
+
+ A successful SETXATTR MUST change the file time_metadata and change
+ attributes if the xattr is created or the value assigned to xattr
+ changes. However, it is not necessary to change these attributes if
+ there has been no actual change in the xattr value. Avoiding
+ attribute change in such situations is desirable as it avoids
+ unnecessary cache invalidation.
+
+ On success, the server returns the change_info4 information in
+ sxr_info. With the atomic field of the change_info4 data type, the
+ server will indicate if the before and after change attributes were
+ obtained atomically with respect to the SETXATTR operation. This
+ allows the client to determine if its cached xattrs are still valid
+ after the operation. See Section 8.7 for a discussion on xattr
+ caching.
+
+8.4.2.4. IMPLEMENTATION
+
+ If the object whose xattr is being changed has a file delegation that
+ is held by a client other than the one doing the SETXATTR, the
+ delegation(s) must be recalled, and the operation cannot proceed to
+ actually change the xattr until each such delegation is returned or
+ revoked. In all cases in which delegations are recalled, the server
+ is likely to return one or more NFS4ERR_DELAY errors while the
+ delegation(s) remains outstanding, although it might not do that if
+ the delegations are returned quickly.
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 16]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+8.4.3. LISTXATTRS - List Extended Attributes of a File
+
+8.4.3.1. ARGUMENTS
+
+ <CODE BEGINS>
+
+ /// struct LISTXATTRS4args {
+ /// /* CURRENT_FH: file */
+ /// nfs_cookie4 lxa_cookie;
+ /// count4 lxa_maxcount;
+ /// };
+
+ <CODE ENDS>
+
+8.4.3.2. RESULTS
+
+ <CODE BEGINS>
+
+ /// struct LISTXATTRS4resok {
+ /// nfs_cookie4 lxr_cookie;
+ /// xattrkey4 lxr_names<>;
+ /// bool lxr_eof;
+ /// };
+
+ /// union LISTXATTRS4res switch (nfsstat4 lxr_status) {
+ /// case NFS4_OK:
+ /// LISTXATTRS4resok lxr_value;
+ /// default:
+ /// void;
+ /// };
+
+ <CODE ENDS>
+
+8.4.3.3. DESCRIPTION
+
+ The LISTXATTRS operation retrieves a variable number of extended
+ attribute keys from the file system object specified by the current
+ filehandle, along with information to allow the client to request
+ additional attribute keys in a subsequent LISTXATTRS.
+
+ The arguments contain a cookie value that represents where the
+ LISTXATTRS should start within the list of xattrs. A value of 0
+ (zero) for lxa_cookie is used to start reading at the beginning of
+ the list. For subsequent LISTXATTRS requests, the client specifies a
+ cookie value that is provided by the server on a previous LISTXATTRS
+ request.
+
+
+
+
+
+Naik & Eshel Standards Track [Page 17]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ The lxa_maxcount value of the argument is the maximum number of bytes
+ for the result. This maximum size represents all of the data being
+ returned within the LISTXATTRS4resok structure and includes the XDR
+ overhead. The server may return less data. If the server is unable
+ to return a single xattr name within the maxcount limit, the error
+ NFS4ERR_TOOSMALL will be returned to the client.
+
+ On successful return, the server's response will provide a list of
+ extended attribute keys. The "lxr_eof" flag has a value of TRUE if
+ there are no more keys for the object.
+
+ The cookie value is only meaningful to the server and is used as a
+ "bookmark" for the xattr key. As mentioned, this cookie is used by
+ the client for subsequent LISTXATTRS operations so that it may
+ continue listing keys. The cookie is similar in concept to a READDIR
+ cookie or the READ offset but should not be interpreted as such by
+ the client.
+
+ On success, the current filehandle retains its value.
+
+8.4.3.4. IMPLEMENTATION
+
+ The handling of a cookie is similar to that of the READDIR operation.
+ It should be a rare occurrence that a server is unable to continue
+ properly listing xattrs with the provided cookie. The server should
+ make every effort to avoid this condition since the application at
+ the client may not be able to properly handle this type of failure.
+
+8.4.4. REMOVEXATTR - Remove an Extended Attribute of a File
+
+8.4.4.1. ARGUMENTS
+
+ <CODE BEGINS>
+
+ /// struct REMOVEXATTR4args {
+ /// /* CURRENT_FH: file */
+ /// xattrkey4 rxa_name;
+ /// };
+
+ <CODE ENDS>
+
+
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 18]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+8.4.4.2. RESULTS
+
+ <CODE BEGINS>
+
+ /// union REMOVEXATTR4res switch (nfsstat4 rxr_status) {
+ /// case NFS4_OK:
+ /// change_info4 rxr_info;
+ /// default:
+ /// void;
+ /// };
+
+ <CODE ENDS>
+
+8.4.4.3. DESCRIPTION
+
+ The REMOVEXATTR operation deletes one extended attribute of a file
+ system object specified by rxa_name. The server MUST return
+ NFS4ERR_NOXATTR if the attribute key does not exist.
+
+ A successful REMOVEXATTR MUST change the file time_metadata and
+ change attributes.
+
+ Similar to SETXATTR, the server communicates the value of the change
+ attribute immediately prior to, and immediately following, a
+ successful REMOVEXATTR operation in rxr_info. This allows the client
+ to determine if its cached xattrs are still valid after the
+ operation. See Section 8.7 for a discussion on xattr caching.
+
+8.4.4.4. IMPLEMENTATION
+
+ If the object whose xattr is being removed has a file delegation that
+ is held by a client other than the one doing the REMOVEXATTR, the
+ delegation(s) must be recalled, and the operation cannot proceed to
+ delete the xattr until each such delegation is returned or revoked.
+ In all cases in which delegations are recalled, the server is likely
+ to return one or more NFS4ERR_DELAY errors while the delegation(s)
+ remains outstanding, although it might not do that if the delegations
+ are returned quickly.
+
+8.4.5. Valid Errors
+
+ This section contains a table that gives the valid error returns for
+ each new protocol operation. The error code NFS4_OK (indicating no
+ error) is not listed but should be understood to be returnable by all
+ new operations. The error values for all other operations are
+ defined in Section 13.2 of [RFC7530] and Section 11.2 of [RFC7862].
+
+
+
+
+
+Naik & Eshel Standards Track [Page 19]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ +-------------+-----------------------------------------------------+
+ | Operation | Errors |
+ +-------------+-----------------------------------------------------+
+ | GETXATTR | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
+ | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
+ | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, NFS4ERR_IO, |
+ | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
+ | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
+ | | NFS4ERR_NOXATTR, NFS4ERR_OP_NOT_IN_SESSION, |
+ | | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, |
+ | | NFS4ERR_REP_TOO_BIG_TO_CACHE, NFS4ERR_REQ_TOO_BIG, |
+ | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_SERVERFAULT, |
+ | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, |
+ | | NFS4ERR_WRONG_TYPE |
+ | SETXATTR | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
+ | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DQUOT, |
+ | | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
+ | | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
+ | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
+ | | NFS4ERR_NOXATTR, NFS4ERR_OP_NOT_IN_SESSION, |
+ | | NFS4ERR_PERM, NFS4ERR_REP_TOO_BIG, |
+ | | NFS4ERR_REP_TOO_BIG_TO_CACHE, NFS4ERR_REQ_TOO_BIG, |
+ | | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS, |
+ | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
+ | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE, |
+ | | NFS4ERR_XATTR2BIG |
+ | LISTXATTRS | NFS4ERR_ACCESS, NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
+ | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
+ | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
+ | | NFS4ERR_NOTSUPP, NFS4ERR_NOXATTR, |
+ | | NFS4ERR_OP_NOT_IN_SESSION, NFS4ERR_PERM, |
+ | | NFS4ERR_REP_TOO_BIG, NFS4ERR_REP_TOO_BIG_TO_CACHE, |
+ | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
+ | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
+ | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+ | REMOVEXATTR | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, NFS4ERR_BADXDR, |
+ | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, NFS4ERR_DQUOT, |
+ | | NFS4ERR_EXIST, NFS4ERR_INVAL, NFS4ERR_IO, |
+ | | NFS4ERR_LOCKED, NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
+ | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
+ | | NFS4ERR_NOXATTR,, NFS4ERR_OLD_STATEID, |
+ | | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
+ | | NFS4ERR_PERM, NFS4ERR_RETRY_UNCACHED_REP, |
+ | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
+ | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
+ +-------------+-----------------------------------------------------+
+
+ Valid Error Returns for Each New Protocol Operation
+
+
+
+Naik & Eshel Standards Track [Page 20]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+8.5. Modifications to Existing Operations
+
+ In order to provide fine-grained access control to query or modify
+ extended attributes, new access rights are defined that can be
+ checked to determine if the client is permitted to perform the xattr
+ operation.
+
+ Note that in general, as explained in Section 18.1.4 of [RFC5661], a
+ client cannot reliably perform an access check with only current file
+ attributes and must verify access with the server.
+
+ This section extends the semantics of the ACCESS operation documented
+ in Section 18.1 of [RFC5661]. Three new access permissions can be
+ requested:
+
+ ACCESS4_XAREAD Query a file or directory for its xattr value
+ given a key.
+
+ ACCESS4_XAWRITE Modify xattr keys and/or values of a file or
+ directory.
+
+ ACCESS4_XALIST Query a file or directory to list its xattr keys.
+
+
+ As with the existing access permissions, the results of ACCESS are
+ advisory in nature, with no implication that such access will be
+ allowed or denied in the future.
+
+ The rules for the client and server follow:
+
+ o If the client is sending ACCESS in order to determine if the user
+ can read an xattr of the file with GETXATTR, the client should set
+ ACCESS4_XAREAD in the request's access field.
+
+ o If the client is sending ACCESS in order to determine if the user
+ can modify an xattr of the file with SETXATTR or REMOVEXATTR, the
+ client should set ACCESS4_XAWRITE in the request's access field.
+
+ o If the client is sending ACCESS in order to determine if the user
+ can list the xattr keys of the file with LISTXATTRS, the client
+ should set ACCESS4_XALIST in the request's access field.
+
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 21]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+8.6. Numeric Values Assigned to Protocol Extensions
+
+ This section lists the numeric values that are assigned new
+ attributes and operations to implement the xattr feature. To avoid
+ inconsistent assignments, these have been checked against the most
+ recent protocol version [RFC5661] and the current minor version
+ [RFC7862]. Development of interoperable prototypes is possible using
+ these values.
+
+ <CODE BEGINS>
+
+ /// /*
+ /// * ACCESS - Check Access Rights
+ /// */
+ /// const ACCESS4_XAREAD = 0x00000040;
+ /// const ACCESS4_XAWRITE = 0x00000080;
+ /// const ACCESS4_XALIST = 0x00000100;
+
+ /// /*
+ /// * New NFSv4 attribute
+ /// */
+ /// typedef bool fattr4_xattr_support;
+
+ /// /*
+ /// * New RECOMMENDED Attribute
+ /// */
+ /// const FATTR4_XATTR_SUPPORT = 82;
+
+ /// /*
+ /// * New NFSv4 operations
+ /// */
+ /// /* Following lines are to be added to enum nfs_opnum4 */
+ /// /*
+ /// OP_GETXATTR = 72,
+ /// OP_SETXATTR = 73,
+ /// OP_LISTXATTRS = 74,
+ /// OP_REMOVEXATTR = 75,
+ /// */
+
+ /// /*
+ /// * New cases for Operation arrays
+ /// */
+ /// /* Following lines are to be added to nfs_argop4 */
+ /// /*
+ /// case OP_GETXATTR: GETXATTR4args opgetxattr;
+ /// case OP_SETXATTR: SETXATTR4args opsetxattr;
+ /// case OP_LISTXATTRS: LISTXATTRS4args oplistxattrs;
+ /// case OP_REMOVEXATTR: REMOVEXATTR4args opremovexattr;
+
+
+
+Naik & Eshel Standards Track [Page 22]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ /// */
+
+ /// /* Following lines are to be added to nfs_resop4 */
+ /// /*
+ /// case OP_GETXATTR: GETXATTR4res opgetxattr;
+ /// case OP_SETXATTR: SETXATTR4res opsetxattr;
+ /// case OP_LISTXATTRS: LISTXATTRS4res oplistxattrs;
+ /// case OP_REMOVEXATTR: REMOVEXATTR4res opremovexattr;
+ /// */
+
+ <CODE ENDS>
+
+8.7. Caching
+
+ The caching behavior for extended attributes is similar to other file
+ attributes such as ACLs and is affected by whether or not OPEN
+ delegation has been granted to a client.
+
+ Xattrs obtained from, or sent to, the server may be cached and
+ clients can use them to avoid subsequent GETXATTR requests, provided
+ that the client can ensure that the cached value has not been
+ subsequently modified by another client. Such assurance can be based
+ on the client holding a delegation for the file in question or the
+ client interrogating the change attribute to make sure that any
+ cached value is still valid. Such caching may be read-only or write-
+ through.
+
+ When a delegation is in effect, some operations by a second client to
+ a delegated file will cause the server to recall the delegation
+ through a callback. For individual operations, we describe, under
+ IMPLEMENTATION, when such operations are required to effect a recall.
+
+ The result of local caching is that the individual xattrs maintained
+ on clients may not be up to date. Changes made in one order on the
+ server may be seen in a different order on one client and in a third
+ order on another client. In order to limit problems that may arise
+ due to separate operations to obtain individual xattrs and other file
+ attributes, a client should treat xattrs just like other file
+ attributes with respect to caching as detailed in Section 10.6 of
+ [RFC7530]. A client may validate its cached version of an xattr for
+ a file by fetching the change attribute and assuming that if the
+ change attribute has the same value as it did when the attributes
+ were cached, then xattrs have not changed. If the client holds a
+ delegation that ensures that the change attribute cannot be modified
+ by another client, it can dispense with actual interrogation of the
+ change attribute.
+
+
+
+
+
+Naik & Eshel Standards Track [Page 23]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+ When a client is changing xattrs of a file, it needs to determine
+ whether there have been changes made to the file by other clients.
+ It does this by using the change attribute as reported before and
+ after the change operation (SETXATTR or REMOVEXATTR) in the
+ associated change_info4 value returned for the operation. The server
+ is able to communicate to the client whether the change_info4 data is
+ provided atomically with respect to the change operation. If the
+ change values are provided atomically, the client has a basis for
+ determining, given proper care, whether other clients are modifying
+ the file in question.
+
+ An effective way to enable the client to make this determination
+ simply is for it to serialize all xattr changes made to a specific
+ file. When this is done, and the server provides before and after
+ values of the change attribute atomically, the client can simply
+ compare the after value of the change attribute from one operation
+ with the before value on the subsequent change operation modifying
+ the file. When these are equal, the client is assured that no other
+ client is modifying the file in question.
+
+ If the comparison indicates that the file was updated by another
+ client, the xattr cache associated with the modified file is purged
+ from the client. If the comparison indicates no modification, the
+ xattr cache can be updated on the client to reflect the file
+ operation, and the associated timeout can be extended. The post-
+ operation change value needs to be saved as the basis for future
+ change_info4 comparisons.
+
+ Xattr caching requires that the client revalidate xattr cache data by
+ inspecting the change attribute of a file at the point when an xattr
+ was cached. This requires that the server update the change
+ attribute when xattrs are modified. For a client to use the
+ change_info4 information appropriately and correctly, the server must
+ report the pre- and post-operation change attribute values
+ atomically. When the server is unable to report the before and after
+ values atomically with respect to the xattr update operation, the
+ server must indicate that fact in the change_info4 return value.
+ When the information is not atomically reported, the client should
+ not assume that other clients have not changed the xattrs.
+
+ The protocol does not provide support for write-back caching of
+ xattrs. As such, all modifications to xattrs should be done by
+ requests to the server. The server should perform such updates
+ synchronously.
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 24]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+8.8. Xattrs and File Locking
+
+ Xattr operations, for the most part, function independent of
+ operations related to file locking state. For example, xattrs can be
+ interrogated and modified without a corresponding OPEN operation.
+ The server does not need to check for locks that conflict with xattr
+ access or modify operations. For example, another OPEN specified
+ with OPEN4_SHARE_DENY_READ or OPEN4_SHARE_DENY_BOTH does not prevent
+ access to or modification of xattrs. Note that the server MUST still
+ verify that the client is allowed to perform the xattr operation on
+ the basis of access permissions.
+
+ However, the presence of delegations may dictate how xattr operations
+ interact with the state-related logic. Xattrs cannot be modified
+ when a delegation for the corresponding file is held by another
+ client. On the other hand, xattrs can be interrogated despite the
+ holding of a write delegation by another client since updates are
+ write-through to the server.
+
+8.9. pNFS Considerations
+
+ All xattr operations are sent to the metadata server, which is
+ responsible for fetching data from and effecting necessary changes to
+ persistent storage.
+
+9. Security Considerations
+
+ Since xattrs are application data, security issues are exactly the
+ same as those relating to the storing of file data and named
+ attributes. Clients MUST NOT accord any system-interpreted semantics
+ to xattrs, since their use is restricted to user-managed metadata
+ only as explained in Section 5. Extended attributes are various
+ sorts of application data, and the fact that the means of reference
+ is slightly different in each case should not be considered security
+ relevant. As such, the additions to the NFS protocol for supporting
+ extended attributes do not alter the security considerations of the
+ NFSv4 protocol [RFC7530].
+
+10. IANA Considerations
+
+ The addition of xattr support to the NFSv4 protocol does not require
+ any actions by IANA. This document limits xattr names to the user
+ namespace, where application developers are allowed to define and use
+ attributes as needed. Unlike named attributes, there is no namespace
+ identifier associated with xattrs that may require registration.
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 25]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+11. References
+
+11.1. Normative References
+
+ [LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents",
+ Version 5.0, March 2015, <http://trustee.ietf.org/docs/
+ IETF-Trust-License-Policy.pdf>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC4506] Eisler, M., Ed., "XDR: External Data Representation
+ Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
+ 2006, <https://www.rfc-editor.org/info/rfc4506>.
+
+ [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
+ "Network File System (NFS) Version 4 Minor Version 1
+ Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
+ <https://www.rfc-editor.org/info/rfc5661>.
+
+ [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
+ (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
+ March 2015, <https://www.rfc-editor.org/info/rfc7530>.
+
+ [RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor
+ Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862,
+ November 2016, <https://www.rfc-editor.org/info/rfc7862>.
+
+ [RFC7863] Haynes, T., "Network File System (NFS) Version 4 Minor
+ Version 2 External Data Representation Standard (XDR)
+ Description", RFC 7863, DOI 10.17487/RFC7863, November
+ 2016, <https://www.rfc-editor.org/info/rfc7863>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8178] Noveck, D., "Rules for NFSv4 Extensions and Minor
+ Versions", RFC 8178, DOI 10.17487/RFC8178, July 2017,
+ <https://www.rfc-editor.org/info/rfc8178>.
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 26]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+11.2. Informative References
+
+ [FreeBSD] FreeBSD, "FreeBSD Manual Pages - extattr", FreeBSD System
+ Calls Manual, January 2008, <http://www.freebsd.org/
+ cgi/man.cgi?query=extattr&sektion=9>.
+
+ [freedesktop]
+ freedesktop, "Guidelines for extended attributes", May
+ 2013, <http://www.freedesktop.org/wiki/
+ CommonExtendedAttributes>.
+
+ [fsattr] Oracle, "fsattr - extended file attributes", Man Pages
+ Section 5: Standards, Environments, and Macros,
+ <http://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02>.
+
+ [KDE] Handa, V., "Extended Attributes Updates", August 2014,
+ <http://vhanda.in/blog/2014/08/
+ extended-attributes-updates/>.
+
+ [Linux] The Linux man-pages project, "Linux Programmer's Manual:
+ xattr(7)", Linux man pages: Section 7, September 2017,
+ <http://man7.org/linux/man-pages/man7/xattr.7.html>.
+
+ [Love] Love, R., "Linux System Programming: Talking Directly to
+ the Kernel and C Library", O'Reilly Media, Inc., February
+ 2009.
+
+ [NTFS] Microsoft, "File Streams", <http://msdn.microsoft.com/en-
+ us/library/windows/desktop/aa364404(v=vs.85).aspx>.
+
+ [POSIX] The Open Group, "System Interfaces of The Open Group Base
+ Specifications Issue 7", IEEE Std 1003.1, 2016 Edition
+ (HTML Version), ISBN 1937218812, September 2016,
+ <http://pubs.opengroup.org/onlinepubs/9699919799/>.
+
+ [Swift] The OpenStack Foundation Wiki, "Swift-on-File", July 2015,
+ <https://wiki.openstack.org/wiki/Swiftonfile>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 27]
+
+RFC 8276 Extended Attributes in NFSv4 December 2017
+
+
+Acknowledgments
+
+ This document has attempted to capture the discussion on adding
+ xattrs to the NFSv4 protocol from many participants on the IETF NFSv4
+ mailing list. Those who provided valuable input and comments on
+ draft versions of this document include: Tom Haynes, Christoph
+ Hellwig, Nico Williams, Dave Noveck, Benny Halevy, and Andreas
+ Gruenbacher.
+
+Authors' Addresses
+
+ Manoj Naik
+ Nutanix
+ 1740 Technology Drive, Suite 150
+ San Jose, CA 95110
+ United States of America
+
+ Email: manoj.naik@nutanix.com
+
+
+ Marc Eshel
+ IBM Almaden
+ 650 Harry Road
+ San Jose, CA 95120
+ United States of America
+
+ Phone: +1 408-927-1894
+ Email: eshel@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Naik & Eshel Standards Track [Page 28]
+