idnits 2.17.1 draft-naik-nfsv4-xattrs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2014) is 3731 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 121, but not defined == Unused Reference: 'KEYWORDS' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC5662' is defined on line 383, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 Working Group M. Naik 3 Internet Draft M. Eshel 4 Intended Status: Standards Track IBM Almaden 5 Expires: August 10, 2014 February 6, 2014 7 Support for File System Extended Attributes in NFSv4 8 draft-naik-nfsv4-xattrs-00 10 Abstract 12 This document proposes extensions to existing NFSv4 operations to 13 allow file extended attributes (here forth also referred to as 14 xattrs) to be manipulated in the protocol. An xattr is a file system 15 feature that allows opaque metadata, not interpreted by the file 16 system, to be associated with files and directories and are supported 17 by many modern file systems. New file attributes are proposed to 18 allow clients to query the server for xattr support, and get and set 19 xattrs on file system objects. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Namespaces and Uses . . . . . . . . . . . . . . . . . . . . . . 3 62 3 Differences with Named Attributes . . . . . . . . . . . . . . . 4 63 4 Protocol Enhancements . . . . . . . . . . . . . . . . . . . . . 5 64 4.1 New Attributes . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2 Attribute Definitions . . . . . . . . . . . . . . . . . . . 5 66 4.2.1 Attribute 82: xattr_support . . . . . . . . . . . . . . 5 67 4.2.2 Attribute 83: maxxattrsize . . . . . . . . . . . . . . 5 68 4.2.3 Attribute 84: xattrsize . . . . . . . . . . . . . . . . 6 69 4.2.4 Attribute 85: xattrs . . . . . . . . . . . . . . . . . 6 70 4.2.5 Attribute 86: xattrnames . . . . . . . . . . . . . . . 6 71 4.3 Extensions to ACE Access Mask Attributes . . . . . . . . . 6 72 4.4 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 5 Issues and Alternatives . . . . . . . . . . . . . . . . . . . . 7 74 5.1 New Operations - GETXATTR, SETXATTR . . . . . . . . . . . . 7 75 5.2 New Operations - GETATTR_PLUS, SETATTR_PLUS . . . . . . . . 8 76 6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 78 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 79 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 81 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1 Introduction 86 Extended attributes are a means to associate opaque metadata with 87 file system objects, typically organized in (name, value) pairs. They 88 are especially useful when they add information that is not, or 89 cannot be, present in the associated object itself. All major 90 operating systems provide various flavors of extended attributes. 91 Many user space tools allow xattrs to be included in attributes that 92 need to be preserved when objects are updated, moved or copied. 94 Extended attributes have long been considered unsuitable for 95 portability because they are inadequately defined and not documented 96 by any standard (such as POSIX). Applications that use or share them 97 need to agree on their format. However, evidence shows that xattrs 98 are widely deployed and their support in disk-based file systems is 99 fairly universal. 101 There are no clear indications on how xattrs can be mapped to any 102 existing recommended or optional file attributes defined in 103 [RFC5661]; thereby most NFS implementations ignore application- 104 specified xattrs. This results in data loss if one copies, over the 105 NFS protocol, a file with xattrs from one file system to another that 106 also supports xattrs. 108 There appears to be relatively strong interest in the community in 109 exposing xattrs over NFS despite the shortcomings. 111 This document discusses why the current NFSv4 named attributes as 112 currently standardized in [RFC5661], are unsuitable for representing 113 xattrs, and proposes alternate language, adjustment and protocol 114 mechanisms to support them. 116 1.1 Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 In this document, these words will appear with that interpretation 123 only when in ALL CAPS. Lower case uses of these words are not to be 124 interpreted as carrying RFC-2119 significance. 126 2 Namespaces and Uses 128 Operating systems may define multiple "namespaces" in which xattrs 129 can be set, but only application-level xattrs that are defined in the 130 "user" namespace can be considered interoperable across platforms and 131 vendor implementations. (For example, Linux defines "security", 132 "system", "trusted" and "user" namespaces. The first three are 133 specific to Linux [1]). As such, this document strongly suggests only 134 allowing user namespace xattrs to be supported. It is recommended 135 that at least one application-specific namespace be used before the 136 attribute, to avoid conflicting use of attributes. Additional text 137 may be required to restrict the allowed namespaces to user-managed 138 metadata only, in order to prevent the development of non- 139 interoperable implementations. 141 Examples of application-specific xattrs include storing metadata that 142 tracks what application created the file, a tag to indicate when the 143 file was last verified by a data integrity scrubber, or a tag to hold 144 a checksum/crypto hash of the file contents along with the date of 145 that signature. Xattrs can also be used for decorations or 146 annotations. For example, a file downloaded from a web server can be 147 tagged with the URL, which can be convenient if its source has to be 148 determined in the future. Likewise, an email attachment can when 149 saved be tagged with the message-id of the email. This will make it 150 possible to trace the original message. Xattrs can be retrieved and 151 set through system calls or shell commands and generally supported by 152 user-space tools that preserve other file attributes. 154 3 Differences with Named Attributes 156 [RFC5661] defines named attributes as opaque byte streams that are 157 associated with a directory or file and referred to by a string name. 158 Named attributes are intended to be used by client applications as a 159 method to associate application-specific data with a regular file or 160 directory. In that sense, xattrs are similar in concept and use to 161 named attributes, but there are subtle differences. 163 File systems typically define xattrs operations such as "get" and 164 "set" as being atomic. Subsequently, xattrs presumably have size 165 limits ranging from a few bytes to several kilobytes, although this 166 is not universally defined. Named attributes, on the other hand, are 167 unbounded data streams and do not impose atomicity requirements. 169 Individual named attributes are analogous to files, and caching of 170 the data for these needs to be handled just as data caching is for 171 ordinary files following close-to-open semantics. Xattrs, on the 172 other hand, impose caching requirements like other file attributes. 174 Named attributes and xattrs have different semantics and belong to 175 disjoint namespaces. As a result, mapping one to another is, at best, 176 a compromise. 178 While it should be possible to write guidance about how a client can 179 use the named attribute mechanism to act like xattrs, such as carving 180 out some namespace and specifying locking primitives, this is 181 problematic. A client application trying to use xattrs through named 182 attributes with a server that supported xattrs directly would get a 183 lower level of service, and could fail to cooperate on a local 184 application running on the server unless a shim layer was also 185 implemented on the server side. File systems that already implement 186 xattrs and named attributes natively would need additional guidance 187 such as reserving named attribute namespace specifically for 188 implementation purposes. 190 4 Protocol Enhancements 192 This section proposes extensions to the NFSv4 protocol operations to 193 allow xattrs to be queried and set by clients. New attributes are 194 proposed to bitmap4 data type to allow xattrs to be queried and set. 195 This follows the guidelines specified in [RFC5661] with respect to 196 minor versioning. 198 4.1 New Attributes 200 The following RECOMMENDED attributes are proposed. A client can query 201 the server to determine if xattrs are supported and the maximum size 202 of the xattrs that are allowed for a file system object. GETATTR and 203 SETATTR can be used to query and set xattrs on an object. 205 A client may ask for any of these attributes to be returned by 206 setting a bit in the GETATTR request but MUST handle the case where 207 the server does not return them. A client may ask for the set of 208 attributes the server supports and SHOULD NOT request attributes the 209 server does not support. 211 +------------------+----+-------------------+-----+----------------+ 212 |Name | Id | Data Type | Acc | Defined in | 213 +------------------+----+-------------------+-----+----------------+ 214 | xattr_support | 82 | Boolean | R | Section 4.2.1 | 215 | maxxattrsize | 83 | uint32_t | R | Section 4.2.2 | 216 | xattrsize | 84 | uint32_t | R | Section 4.2.3 | 217 | xattrs | 85 | xattr4<> | R W | Section 4.2.4 | 218 | xattrnames | 86 | xattrname4<> | R | Section 4.2.5 | 219 +------------------+----+-------------------+-----+----------------+ 221 4.2 Attribute Definitions 223 4.2.1 Attribute 82: xattr_support 225 TRUE, if the object's file system supports extended attributes. 227 4.2.2 Attribute 83: maxxattrsize 228 Maximum size in bytes of all the extended attributes per object that 229 the object's file system supports. 231 4.2.3 Attribute 84: xattrsize 233 The total size of all the extended attributes of this object in 234 bytes. 236 4.2.4 Attribute 85: xattrs 238 The xattrs attribute contains an array of extended attributes that 239 are associated with the file system object. Although the client can 240 get and set xattrs, the server is responsible for using the xattrs 241 for its own purposes. Any regular file or directory may have xattrs, 242 each consisting of a name and associated data. Similar to ACLs, the 243 client can use the OPEN or ACCESS operations to check access without 244 modifying or reading data or metadata. For SETATTR operation, if the 245 associated xattrvalue4 has a length of zero, the corresponding xattr 246 is to be deleted, if it exists. Specific names of attributes will not 247 be controlled by this document or other IETF Standards Track 248 documents. 250 The NFS xattr structure is defined as follows: 252 typedef utf8str_cis xattrname4; 253 typedef opaque xattrvalue4<>; 255 struct xattr4 { 256 xattrname4 xa_name; 257 xattrvalue4 xa_value; 258 }; 260 4.2.5 Attribute 86: xattrnames 262 The xattrnames is similar to xattrs attribute, except that it only 263 returns the names of the xattrs for the file system object without 264 the values. Each xattr is a tuple of the form (name, value). 265 xattrname4 is a UTF-8 string denoting the xattr name, xattrvalue4 is 266 a variable length string that identifies the values of a specified 267 xattr. The NFS client or server must not interpret the value. 269 4.3 Extensions to ACE Access Mask Attributes 271 Two new bitmask constants are proposed for the access mask field: 273 const ACE4_READ_XATTRS = 0x00200000; 274 const ACE4_WRITE_XATTRS = 0x00400000; 276 Permission to read and write the extended attributes of a file. The 277 affected operations are GETATTR and SETATTR respectively. No 278 additional granularity of control is implied by these constants for 279 server implementations. 281 4.4 Caching 283 Similar to other attributes like ACLs, clients may cache xattrs 284 obtained from the server and use them to avoid subsequent GETATTR 285 requests. Similarly, such caching is write through in that 286 modification to file attributes is always done by means of requests 287 to the server and should not be done locally and should not be 288 cached. Due to the relative infrequency of xattr updates, it is 289 suggested that all changes be propagated synchronously. 291 5 Issues and Alternatives 293 The proposed bitmap changes treat the object xattrs as a single 294 attribute, allowing them to be read and written in a single GETATTR 295 or SETATTR request respectively, similar to other metadata attributes 296 (such as ACLs). In reality, most file systems allow disparate 297 metadata to be associated with an object through xattrs, where 298 combining them into a single entity is unwieldy. For example, 299 obtaining the value of a single xattr using the bitmap would require 300 a client implementation to read all the xattrs of the file and find a 301 match for the one requested. Similarly, replacing or deleting a 302 single xattr while keeping the others intact would require a client 303 to read the xattrs first, replacing the existing list with a modified 304 list that excludes the one to be deleted, and writing out the 305 remaining xattrs. 307 5.1 New Operations - GETXATTR, SETXATTR 309 An alternative to modifying the existing attribute bitmap is to 310 introduce two separate operations, such as GETXATTR and SETXATTR, 311 that allow querying and setting of xattrs. This has the advantage of 312 allowing new functionality that is otherwise difficult to support 313 with existing operations. For example, GETXATTR could allow listing 314 all the xattrs names, names with values, or querying the value of a 315 single name. SETXATTR could allow deleting a single xattr or 316 replacing a few without modifying the rest. 318 The disadvantage of defining entirely new operations is with 319 specifying consistency semantics with respect to existing operations. 320 For example, modifying a file's xattrs also affects its time_metadata 321 attribute. Obtaining these through separate RPC operations (GETATTR 322 and GETXATTR) would violate cache consistency semantics. 324 5.2 New Operations - GETATTR_PLUS, SETATTR_PLUS 326 Another option is to define new operations, GETATTR_PLUS and 327 SETATTR_PLUS, that support all the features of the existing NFSv4 328 GETATTR and SETATTR operations, but allow more information to be 329 specified to the server, and add information to the format of the 330 response, in addition to attribute bitmap. 332 6 Related Work 334 Extended attributes are supported by many file systems. 336 In Linux, the ext2, ext3, ext4, JFS, ReiserFS, XFS, Btrfs and OCFS2 337 file systems support extended attributes. The getfattr and setfattr 338 utilities can be used to retrieve and set xattrs. The names of the 339 extended attributes must be prefixed by the name of the category and 340 a dot; hence these categories are generally qualified as name spaces. 341 Currently, four namespaces exist: user, trusted, security and system. 342 Recommendations on how they should be used are published by 343 freedesktop.org [1]. 345 In FreeBSD, the UFS1 and UFS2 file systems (5.0 and later) and XFS 346 (8.0 and later) support extended attributes in two namespaces - user 347 and system. The associated utilities are getextattr, lsextattr, 348 rmextattr, and setextattr. 350 Solaris (9 and later) allows files to have extended attributes, but 351 implements them as "forks". 353 On Windows NT, limited-length extended attributes are supported by 354 FAT, HPFS, and NTFS. Additionally, NTFS can support infinite-length 355 extended attributes in the form of Alternate Data Streams (ADS), a 356 type of resource fork. 358 Mac OS X 10.4 and later support extended attributes through open name 359 spaces enabled through a mount option. 361 7 Security Considerations 363 The additions to the NFS protocol for supporting extended attributes 364 do not alter the security considerations of the NFSv4.1 protocol 365 [RFC5661]. 367 8 IANA Considerations 369 There are no IANA considerations in this document. All NFSv4.1 IANA 370 considerations are covered in [RFC5661]. 372 9 References 374 9.1 Normative References 376 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 380 "Network File System (NFS) Version 4 Minor Version 1 381 Protocol", RFC 5661, January 2010. 383 [RFC5662] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 384 "Network File System (NFS) Version 4 Minor Version 1 385 External Data Representation Standard (XDR) Description", 386 RFC 5662, January 2010. 388 9.2 Informative References 390 [1] http://www.freedesktop.org/wiki/CommonExtendedAttributes, 391 "Guidelines for extended attributes". 393 Authors' Addresses 395 Manoj Naik 396 IBM Almaden 397 650 Harry Rd 398 San Jose, CA 95120 400 Phone: +1 408-927-1707 401 Email: mnaik@us.ibm.com 403 Marc Eshel 404 IBM Almaden 405 650 Harry Rd 406 San Jose, CA 95120 408 Phone: +1 408-927-1894 409 Email: eshel@us.ibm.com