File System Extended Attributes in NFSv4

A new separate protocol mechanism was created rather than mapping xattrs to named attributes because such a mapping would be a compromise: a client using xattrs through named attributes with a server supporting xattrs directly would get a lower level of service, and file systems implementing both natively would need additional guidance on namespace reservation.

Named attributes were not reused for xattrs because they have fundamentally different semantics: xattrs are atomic per-attribute operations with size limits fitting in a single COMPOUND request, while named attributes are unbounded data streams opened and closed like files with close-to-open caching semantics.

Only the 'user' namespace is supported for xattrs in NFSv4, avoiding the need to specify semantics for system-interpreted namespaces (security, trusted, system) that are platform-specific and non-interoperable.

All xattr operations in a pNFS environment are sent to the metadata server, not to data servers, as the metadata server is responsible for fetching and updating xattr data in persistent storage.

Some server implementations may not be aware of the new xattr operations and may return NFS4ERR_OP_ILLEGAL or an XDR decode error rather than NFS4ERR_NOTSUPP. Clients should only issue these operations after determining that support is present.

Xattr caching behavior is similar to ACLs and other file attributes: clients may use the change attribute to revalidate cached xattrs, or rely on a held delegation. Write-back caching is not supported; all modifications must be sent to the server synchronously.

Xattr operations function independently of file locking state and do not require a corresponding OPEN; share denials (OPEN4_SHARE_DENY_READ, OPEN4_SHARE_DENY_BOTH) do not prevent xattr access or modification. However, xattrs cannot be modified when a delegation for the file is held by another client.

A server MUST support all four xattr operations (GETXATTR, SETXATTR, LISTXATTRS, REMOVEXATTR) when directed to a file system that supports xattr_support and returns TRUE. For file systems that do not support xattr_support or return FALSE, all four operations MUST NOT be supported.

Clients MUST NOT accord any system-interpreted semantics to xattrs, as their use is restricted to user-managed metadata only.

security

GETXATTR: If the server does not support xattrs on the target file system, it MUST NOT return a value and MUST return NFS4ERR_NOTSUPP. The server MUST return NFS4ERR_NOXATTR if xattrs are supported but the requested data cannot be obtained. If the response would exceed the channel's maximum size, the server MUST return NFS4ERR_REP_TOO_BIG.

REMOVEXATTR: 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.

SETXATTR with SETXATTR4_CREATE MUST return NFS4ERR_EXIST if the attribute key already exists; SETXATTR4_REPLACE MUST return NFS4ERR_NOXATTR if the attribute key does not exist. A successful SETXATTR MUST change the file time_metadata and change attributes if the xattr is created or its value changes.

The server must report pre- and post-operation change attribute values atomically for SETXATTR and REMOVEXATTR. When unable to report them atomically, the server must indicate this in the change_info4 return value, and the client should not assume other clients have not changed the xattrs.

The server MUST still verify that the client is allowed to perform the xattr operation on the basis of access permissions, even though xattr operations function independently of file locking state and do not require a corresponding OPEN operation.

security

Xattr keys and values MUST NOT be interpreted by NFS clients or servers; they are treated as opaque application data. Interpretation would lead to non-interoperable implementations.

Four new OPTIONAL operations are defined: GETXATTR (OP=72), SETXATTR (OP=73), LISTXATTRS (OP=74), and REMOVEXATTR (OP=75). These allow clients to get, set, list, and remove xattrs on file system objects.

NFS4ERR_NOXATTR (error code 10095) is returned when the specified xattr does not exist or cannot be retrieved. NFS4ERR_XATTR2BIG (error code 10096) is returned when the xattr value or collective xattr size exceeds the file system's limit.

Three new ACCESS permission bits are defined: ACCESS4_XAREAD (0x00000040) for reading xattr values, ACCESS4_XAWRITE (0x00000080) for modifying xattr keys/values, and ACCESS4_XALIST (0x00000100) for listing xattr keys.

xattr_support is a per-filesystem read-only boolean attribute (FATTR4_XATTR_SUPPORT = 82) that indicates whether the file system supports extended attributes. Clients should check supported_attrs before querying this attribute.

registry

Security issues for xattrs are identical to those for file data and named attributes. The additions to NFSv4 for xattr support do not alter the base NFSv4 security considerations, since xattrs are application data with no system-interpreted semantics.

security

GETXATTR4args contains a single field gxa_name (xattrkey4) identifying the requested attribute. On success, GETXATTR4res returns gxr_value (xattrvalue4); on failure, the result is void.

LISTXATTRS4args contains lxa_cookie (nfs_cookie4, 0 for start) and lxa_maxcount (count4). The success result LISTXATTRS4resok contains lxr_cookie, lxr_names (array of xattrkey4), and lxr_eof (bool).

REMOVEXATTR4args contains rxa_name (xattrkey4). On success, REMOVEXATTR4res returns rxr_info (change_info4) capturing before/after change attributes atomically.

SETXATTR4args contains sxa_option (setxattr_option4 enum: SETXATTR4_EITHER=0, SETXATTR4_CREATE=1, SETXATTR4_REPLACE=2), sxa_key (xattrkey4), and sxa_value (xattrvalue4). On success, SETXATTR4res returns sxr_info (change_info4).

xattrkey4 is typed as component4 (a string) identifying the xattr key name. xattrvalue4 is a variable-length opaque byte string holding the xattr value. These are the two XDR base types for the xattr extension.