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

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/