draft-ietf-nfsv4-minorversion2-19.txt   draft-ietf-nfsv4-minorversion2-20.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track March 14, 2013 Intended status: Standards Track August 13, 2013
Expires: September 15, 2013 Expires: February 14, 2014
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-19.txt draft-ietf-nfsv4-minorversion2-20.txt
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version two, This Internet-Draft describes NFS version 4 minor version two,
focusing mainly on the protocol extensions made from NFS version 4 focusing mainly on the protocol extensions made from NFS version 4
minor version 0 and NFS version 4 minor version 1. Major extensions minor version 0 and NFS version 4 minor version 1. Major extensions
introduced in NFS version 4 minor version two include: Server-side introduced in NFS version 4 minor version two include: Server-side
Copy, Application I/O Advise, Space Reservations, Sparse Files, Copy, Application I/O Advise, Space Reservations, Sparse Files,
Application Data Blocks, and Labeled NFS. Application Data Blocks, and Labeled NFS.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2013. This Internet-Draft will expire on February 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 (http://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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3.2.1. Overview of Copy Operations . . . . . . . . . . . . . 11 3.2.1. Overview of Copy Operations . . . . . . . . . . . . . 11
3.2.2. Locking the Files . . . . . . . . . . . . . . . . . . 12 3.2.2. Locking the Files . . . . . . . . . . . . . . . . . . 12
3.2.3. Intra-Server Copy . . . . . . . . . . . . . . . . . . 12 3.2.3. Intra-Server Copy . . . . . . . . . . . . . . . . . . 12
3.2.4. Inter-Server Copy . . . . . . . . . . . . . . . . . . 14 3.2.4. Inter-Server Copy . . . . . . . . . . . . . . . . . . 14
3.2.5. Server-to-Server Copy Protocol . . . . . . . . . . . . 18 3.2.5. Server-to-Server Copy Protocol . . . . . . . . . . . . 18
3.3. Requirements for Operations . . . . . . . . . . . . . . . 19 3.3. Requirements for Operations . . . . . . . . . . . . . . . 19
3.3.1. netloc4 - Network Locations . . . . . . . . . . . . . 20 3.3.1. netloc4 - Network Locations . . . . . . . . . . . . . 20
3.3.2. Copy Offload Stateids . . . . . . . . . . . . . . . . 20 3.3.2. Copy Offload Stateids . . . . . . . . . . . . . . . . 20
3.4. Security Considerations . . . . . . . . . . . . . . . . . 21 3.4. Security Considerations . . . . . . . . . . . . . . . . . 21
3.4.1. Inter-Server Copy Security . . . . . . . . . . . . . . 21 3.4.1. Inter-Server Copy Security . . . . . . . . . . . . . . 21
4. Support for Application IO Hints . . . . . . . . . . . . . . . 29 4. Support for Application IO Hints . . . . . . . . . . . . . . . 23
5. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . . 29 5. Sparse Files . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 29 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 24
5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 30 5.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. New Operations . . . . . . . . . . . . . . . . . . . . . 30 5.3. New Operations . . . . . . . . . . . . . . . . . . . . . 25
5.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 31 5.3.1. READ_PLUS . . . . . . . . . . . . . . . . . . . . . . 25
5.3.2. WRITE_PLUS . . . . . . . . . . . . . . . . . . . . . . 31 5.3.2. WRITE_PLUS . . . . . . . . . . . . . . . . . . . . . . 25
6. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 31 6. Space Reservation . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 26
7. Application Data Hole Support . . . . . . . . . . . . . . . . 33 7. Application Data Hole Support . . . . . . . . . . . . . . . . 28
7.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 34 7.1. Generic Framework . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Data Hole Representation . . . . . . . . . . . . . . . 35 7.1.1. Data Hole Representation . . . . . . . . . . . . . . . 29
7.1.2. Data Content . . . . . . . . . . . . . . . . . . . . . 35 7.1.2. Data Content . . . . . . . . . . . . . . . . . . . . . 30
7.2. An Example of Detecting Corruption . . . . . . . . . . . 36 7.2. An Example of Detecting Corruption . . . . . . . . . . . 30
7.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 37 7.3. Example of READ_PLUS . . . . . . . . . . . . . . . . . . 31
8. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 32
8.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 39 8.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 33
8.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 39 8.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 34
8.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 40 8.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 34
8.3.2. Permission Checking . . . . . . . . . . . . . . . . . 40 8.3.2. Permission Checking . . . . . . . . . . . . . . . . . 35
8.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 41 8.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 35
8.3.4. Existing Objects . . . . . . . . . . . . . . . . . . . 41 8.3.4. Existing Objects . . . . . . . . . . . . . . . . . . . 35
8.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 41 8.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 35
8.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 42 8.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 36
8.5. Discovery of Server Labeled NFS Support . . . . . . . . . 42 8.5. Discovery of Server Labeled NFS Support . . . . . . . . . 36
8.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 42 8.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 36
8.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 43 8.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 36
8.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 44 8.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 38
8.7. Security Considerations . . . . . . . . . . . . . . . . . 44 8.7. Security Considerations . . . . . . . . . . . . . . . . . 38
9. Sharing change attribute implementation details with NFSv4 9. Sharing change attribute implementation details with NFSv4
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 45 9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 39
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 45 11. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Error Definitions . . . . . . . . . . . . . . . . . . . . 46 11.1. Error Definitions . . . . . . . . . . . . . . . . . . . . 40
11.1.1. General Errors . . . . . . . . . . . . . . . . . . . . 46 11.1.1. General Errors . . . . . . . . . . . . . . . . . . . . 40
11.1.2. Server to Server Copy Errors . . . . . . . . . . . . . 46 11.1.2. Server to Server Copy Errors . . . . . . . . . . . . . 40
11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . . 47 11.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . . 41
11.2. New Operations and Their Valid Errors . . . . . . . . . . 47 11.2. New Operations and Their Valid Errors . . . . . . . . . . 41
11.3. New Callback Operations and Their Valid Errors . . . . . 50 11.3. New Callback Operations and Their Valid Errors . . . . . 44
12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 51 12. New File Attributes . . . . . . . . . . . . . . . . . . . . . 45
12.1. New RECOMMENDED Attributes - List and Definition 12.1. New RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 51 References . . . . . . . . . . . . . . . . . . . . . . . 45
12.2. Attribute Definitions . . . . . . . . . . . . . . . . . . 52 12.2. Attribute Definitions . . . . . . . . . . . . . . . . . . 46
13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . . 55 13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . . 49
14. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . . 59 14. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Operation 59: COPY - Initiate a server-side copy . . . . 59 14.1. Operation 59: COPY - Initiate a server-side copy . . . . 53
14.2. Operation 60: OFFLOAD_ABORT - Cancel a server-side 14.2. Operation 60: OFFLOAD_ABORT - Cancel a server-side
copy . . . . . . . . . . . . . . . . . . . . . . . . . . 66 copy . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14.3. Operation 61: COPY_NOTIFY - Notify a source server of 14.3. Operation 61: COPY_NOTIFY - Notify a source server of
a future copy . . . . . . . . . . . . . . . . . . . . . . 67 a future copy . . . . . . . . . . . . . . . . . . . . . . 57
14.4. Operation 62: OFFLOAD_REVOKE - Revoke a destination 14.4. Operation 62: OFFLOAD_REVOKE - Revoke a destination
server's copy privileges . . . . . . . . . . . . . . . . 68 server's copy privileges . . . . . . . . . . . . . . . . 58
14.5. Operation 63: OFFLOAD_STATUS - Poll for status of a 14.5. Operation 63: OFFLOAD_STATUS - Poll for status of a
server-side copy . . . . . . . . . . . . . . . . . . . . 69 server-side copy . . . . . . . . . . . . . . . . . . . . 59
14.6. Modification to Operation 42: EXCHANGE_ID - 14.6. Modification to Operation 42: EXCHANGE_ID -
Instantiate Client ID . . . . . . . . . . . . . . . . . . 70 Instantiate Client ID . . . . . . . . . . . . . . . . . . 60
14.7. Operation 64: WRITE_PLUS . . . . . . . . . . . . . . . . 71 14.7. Operation 64: WRITE_PLUS . . . . . . . . . . . . . . . . 61
14.8. Operation 67: IO_ADVISE - Application I/O access 14.8. Operation 67: IO_ADVISE - Application I/O access
pattern hints . . . . . . . . . . . . . . . . . . . . . . 77 pattern hints . . . . . . . . . . . . . . . . . . . . . . 67
14.9. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 82 14.9. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 72
14.10. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 85 14.10. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 75
14.11. Operation 66: SEEK . . . . . . . . . . . . . . . . . . . 90 14.11. Operation 66: SEEK . . . . . . . . . . . . . . . . . . . 80
15. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 91 15. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 81
15.1. Operation 15: CB_OFFLOAD - Report results of an 15.1. Operation 15: CB_OFFLOAD - Report results of an
asynchronous operation . . . . . . . . . . . . . . . . . 91 asynchronous operation . . . . . . . . . . . . . . . . . 81
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 93 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83
17.1. Normative References . . . . . . . . . . . . . . . . . . 93 17.1. Normative References . . . . . . . . . . . . . . . . . . 83
17.2. Informative References . . . . . . . . . . . . . . . . . 93 17.2. Informative References . . . . . . . . . . . . . . . . . 83
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 95 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 85
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 96 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 85
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 2 Protocol 1.1. The NFS Version 4 Minor Version 2 Protocol
The NFS version 4 minor version 2 (NFSv4.2) protocol is the third The NFS version 4 minor version 2 (NFSv4.2) protocol is the third
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0, is described in [I-D.ietf-nfsv4-rfc3530bis] and the version, NFSv4.0, is described in [I-D.ietf-nfsv4-rfc3530bis] and the
second minor version, NFSv4.1, is described in [RFC5661]. It follows second minor version, NFSv4.1, is described in [RFC5661]. It follows
the guidelines for minor versioning that are listed in Section 11 of the guidelines for minor versioning that are listed in Section 11 of
skipping to change at page 9, line 4 skipping to change at page 9, line 4
* extending enumerated types (including NFS4ERR_*) with new * extending enumerated types (including NFS4ERR_*) with new
values values
* adding cases to a switched union * adding cases to a switched union
4. Note that when adding new cases to a switched union, a minor 4. Note that when adding new cases to a switched union, a minor
version must not make new cases be REQUIRED. While the version must not make new cases be REQUIRED. While the
encapsulating operation may be REQUIRED, the new cases (the encapsulating operation may be REQUIRED, the new cases (the
specific arm of the discriminated union) is not. The error code specific arm of the discriminated union) is not. The error code
NFS4ERR_UNION_NOTSUPP is used to notifify the client when the NFS4ERR_UNION_NOTSUPP is used to notify the client when the
server does not support such a case. server does not support such a case.
5. Minor versions must not modify the structure of existing 5. Minor versions must not modify the structure of existing
attributes. attributes.
6. Minor versions must not delete operations. 6. Minor versions must not delete operations.
This prevents the potential reuse of a particular operation This prevents the potential reuse of a particular operation
"slot" in a future minor version. "slot" in a future minor version.
skipping to change at page 10, line 9 skipping to change at page 10, line 9
put in place to mitigate the effects of design and put in place to mitigate the effects of design and
implementation mistakes, and to allow protocol development to implementation mistakes, and to allow protocol development to
adapt to unexpected changes in the pace of implementation. Even adapt to unexpected changes in the pace of implementation. Even
if an operation is marked OBSOLESCENT in a given minor version, if an operation is marked OBSOLESCENT in a given minor version,
it may end up not being marked MANDATORY TO NOT implement in the it may end up not being marked MANDATORY TO NOT implement in the
next minor version. In unusual circumstances, it might not be next minor version. In unusual circumstances, it might not be
marked OBSOLESCENT in a subsequent minor version, and never marked OBSOLESCENT in a subsequent minor version, and never
become MANDATORY TO NOT implement. become MANDATORY TO NOT implement.
12. Minor versions may downgrade features from REQUIRED to 12. Minor versions may downgrade features from REQUIRED to
RECOMMENDED, from RECOMMENDED to OPTIONAL, or from OPIONAL to RECOMMENDED, from RECOMMENDED to OPTIONAL, or from OPTIONAL to
MANDATORY TO NOT implement. Also, if a feature was marked as MANDATORY TO NOT implement. Also, if a feature was marked as
OBSOLESCENT in the prior minor version, it may be downgraded OBSOLESCENT in the prior minor version, it may be downgraded
from REQUIRED to OPTIONAL from RECOMMENDED to MANDATORY TO NOT from REQUIRED to OPTIONAL from RECOMMENDED to MANDATORY TO NOT
implement, or from REQUIRED to MANDATORY TO NOT implement. implement, or from REQUIRED to MANDATORY TO NOT implement.
13. Minor versions may upgrade features from OPTIONAL to 13. Minor versions may upgrade features from OPTIONAL to
RECOMMENDED, or RECOMMENDED to REQUIRED. Also, if a feature was RECOMMENDED, or RECOMMENDED to REQUIRED. Also, if a feature was
marked as OBSOLESCENT in the prior minor version, it may be marked as OBSOLESCENT in the prior minor version, it may be
upgraded to not be OBSOLESCENT. upgraded to not be OBSOLESCENT.
skipping to change at page 18, line 13 skipping to change at page 18, line 13
Figure 5: An asynchronous inter-server copy. Figure 5: An asynchronous inter-server copy.
3.2.5. Server-to-Server Copy Protocol 3.2.5. Server-to-Server Copy Protocol
The source server and destination server are not required to use a The source server and destination server are not required to use a
specific protocol to transfer the file data. The choice of what specific protocol to transfer the file data. The choice of what
protocol to use is ultimately the destination server's decision. protocol to use is ultimately the destination server's decision.
3.2.5.1. Using NFSv4.x as a Server-to-Server Copy Protocol 3.2.5.1. Using NFSv4.x as a Server-to-Server Copy Protocol
The destination server MAY use standard NFSv4.x (where x >= 1) to The destination server MAY use standard NFSv4.x (where x >= 1)
read the data from the source server. If NFSv4.x is used for the operations to read the data from the source server. If NFSv4.x is
server-to-server copy protocol, the destination server can use the used for the server-to-server copy protocol, the destination server
filehandle contained in the COPY request with standard NFSv4.x can use the source filehandle provided in the COPY request with
operations to read data from the source server. Specifically, the standard NFSv4.x operations to read data from the source server.
destination server may use the NFSv4.x OPEN operation's CLAIM_FH Specifically, the destination server may use the NFSv4.x OPEN
facility to open the file being copied and obtain an open stateid. operation's CLAIM_FH facility to open the file being copied and
Using the stateid, the destination server may then use NFSv4.x READ obtain an open stateid. Using the stateid, the destination server
operations to read the file. may then use NFSv4.x READ operations to read the file.
3.2.5.2. Using an alternative Server-to-Server Copy Protocol 3.2.5.2. Using an alternative Server-to-Server Copy Protocol
In a homogeneous environment, the source and destination servers In a homogeneous environment, the source and destination servers
might be able to perform the file copy extremely efficiently using might be able to perform the file copy extremely efficiently using
specialized protocols. For example the source and destination specialized protocols. For example the source and destination
servers might be two nodes sharing a common file system format for servers might be two nodes sharing a common file system format for
the source and destination file systems. Thus the source and the source and destination file systems. Thus the source and
destination are in an ideal position to efficiently render the image destination are in an ideal position to efficiently render the image
of the source file to the destination file by replicating the file of the source file to the destination file by replicating the file
skipping to change at page 19, line 15 skipping to change at page 19, line 15
destination server receives the source server's URL, it would use destination server receives the source server's URL, it would use
"_FH/0x12345" as the file name to pass to the FTP server listening on "_FH/0x12345" as the file name to pass to the FTP server listening on
port 9999 of s1.example.com. On port 9999 there would be a special port 9999 of s1.example.com. On port 9999 there would be a special
instance of the FTP service that understands how to convert NFS instance of the FTP service that understands how to convert NFS
filehandles to an open file descriptor (in many operating systems, filehandles to an open file descriptor (in many operating systems,
this would require a new system call, one which is the inverse of the this would require a new system call, one which is the inverse of the
makefh() function that the pre-NFSv4 MOUNT service needs). makefh() function that the pre-NFSv4 MOUNT service needs).
Authenticating and identifying the destination server to the source Authenticating and identifying the destination server to the source
server is also a challenge. Recommendations for how to accomplish server is also a challenge. Recommendations for how to accomplish
this are given in Section 3.4.1.2.4 and Section 3.4.1.4. this are given in Section 3.4.1.3.
3.3. Requirements for Operations 3.3. Requirements for Operations
The implementation of server-side copy is OPTIONAL by the client and The implementation of server-side copy is OPTIONAL by the client and
the server. However, in order to successfully copy a file, some the server. However, in order to successfully copy a file, some
operations MUST be supported by the client and/or server. operations MUST be supported by the client and/or server.
If a client desires an intra-server file copy, then it MUST support If a client desires an intra-server file copy, then it MUST support
the COPY and CB_OFFLOAD operations. If COPY returns a stateid, then the COPY and CB_OFFLOAD operations. If COPY returns a stateid, then
the client MAY use the OFFLOAD_ABORT and OFFLOAD_STATUS operations. the client MAY use the OFFLOAD_ABORT and OFFLOAD_STATUS operations.
skipping to change at page 21, line 21 skipping to change at page 21, line 21
3.4. Security Considerations 3.4. Security Considerations
The security considerations pertaining to NFSv4 The security considerations pertaining to NFSv4
[I-D.ietf-nfsv4-rfc3530bis] apply to this chapter. [I-D.ietf-nfsv4-rfc3530bis] apply to this chapter.
The standard security mechanisms provide by NFSv4 The standard security mechanisms provide by NFSv4
[I-D.ietf-nfsv4-rfc3530bis] may be used to secure the protocol [I-D.ietf-nfsv4-rfc3530bis] may be used to secure the protocol
described in this chapter. described in this chapter.
NFSv4 clients and servers supporting the inter-server copy operations NFSv4 clients and servers supporting the inter-server copy operations
described in this chapter are REQUIRED to implement [rpcsecgssv3], described in this chapter are REQUIRED to implement the mechanism
including the RPCSEC_GSSv3 privileges copy_from_auth and described in Section 3.4.1.2, and to support rejecting COPY_NOTIFY
copy_to_auth. If the server-to-server copy protocol is ONC RPC requests that do not use RPCSEC_GSS with privacy. This requirement
based, the servers are also REQUIRED to implement the RPCSEC_GSSv3 to implement is not a requirement to use; for example, a server may
privilege copy_confirm_auth. These requirements to implement are not depending on configuration also allow COPY_NOTIFY requests that use
requirements to use. NFSv4 clients and servers are RECOMMENDED to only AUTH_SYS.
use [rpcsecgssv3] to secure server-side copy operations.
3.4.1. Inter-Server Copy Security 3.4.1. Inter-Server Copy Security
3.4.1.1. Requirements for Secure Inter-Server Copy 3.4.1.1. Requirements for Secure Inter-Server Copy
Inter-server copy is driven by several requirements: Inter-server copy is driven by several requirements:
o The specification MUST NOT mandate an inter-server copy protocol. o The specification must not mandate an inter-server copy protocol.
There are many ways to copy data. Some will be more optimal than There are many ways to copy data. Some will be more optimal than
others depending on the identities of the source server and others depending on the identities of the source server and
destination server. For example the source and destination destination server. For example the source and destination
servers might be two nodes sharing a common file system format for servers might be two nodes sharing a common file system format for
the source and destination file systems. Thus the source and the source and destination file systems. Thus the source and
destination are in an ideal position to efficiently render the destination are in an ideal position to efficiently render the
image of the source file to the destination file by replicating image of the source file to the destination file by replicating
the file system formats at the block level. In other cases, the the file system formats at the block level. In other cases, the
source and destination might be two nodes sharing a common storage source and destination might be two nodes sharing a common storage
area network, and thus there is no need to copy any data at all, area network, and thus there is no need to copy any data at all,
and instead ownership of the file and its contents simply gets re- and instead ownership of the file and its contents simply gets re-
assigned to the destination. assigned to the destination.
o The specification MUST provide guidance for using NFSv4.x as a o The specification must provide guidance for using NFSv4.x as a
copy protocol. For those source and destination servers willing copy protocol. For those source and destination servers willing
to use NFSv4.x there are specific security considerations that to use NFSv4.x there are specific security considerations that
this specification can and does address. this specification can and does address.
o The specification MUST NOT mandate pre-configuration between the o The specification must not mandate pre-configuration between the
source and destination server. Requiring that the source and source and destination server. Requiring that the source and
destination first have a "copying relationship" increases the destination first have a "copying relationship" increases the
administrative burden. However the specification MUST NOT administrative burden. However the specification MUST NOT
preclude implementations that require pre-configuration. preclude implementations that require pre-configuration.
o The specification MUST NOT mandate a trust relationship between o The specification must not mandate a trust relationship between
the source and destination server. The NFSv4 security model the source and destination server. The NFSv4 security model
requires mutual authentication between a principal on an NFS requires mutual authentication between a principal on an NFS
client and a principal on an NFS server. This model MUST continue client and a principal on an NFS server. This model MUST continue
with the introduction of COPY. with the introduction of COPY.
3.4.1.2. Inter-Server Copy with RPCSEC_GSSv3 3.4.1.2. Inter-Server Copy via ONC RPC
When the client sends a COPY_NOTIFY to the source server to expect
the destination to attempt to copy data from the source server, it is
expected that this copy is being done on behalf of the principal
(called the "user principal") that sent the RPC request that encloses
the COMPOUND procedure that contains the COPY_NOTIFY operation. The
user principal is identified by the RPC credentials. A mechanism
that allows the user principal to authorize the destination server to
perform the copy in a manner that lets the source server properly
authenticate the destination's copy, and without allowing the
destination to exceed its authorization is necessary.
An approach that sends delegated credentials of the client's user
principal to the destination server is not used for the following
reasons. If the client's user delegated its credentials, the
destination would authenticate as the user principal. If the
destination were using the NFSv4 protocol to perform the copy, then
the source server would authenticate the destination server as the
user principal, and the file copy would securely proceed. However,
this approach would allow the destination server to copy other files.
The user principal would have to trust the destination server to not
do so. This is counter to the requirements, and therefore is not
considered. Instead an approach using RPCSEC_GSSv3 [rpcsecgssv3]
privileges is proposed.
One of the stated applications of the proposed RPCSEC_GSSv3 protocol
is compound client host and user authentication [+ privilege
assertion]. For inter-server file copy, we require compound NFS
server host and user authentication [+ privilege assertion]. The
distinction between the two is one without meaning.
RPCSEC_GSSv3 introduces the notion of privileges. We define three
privileges:
copy_from_auth: A user principal is authorizing a source principal
("nfs@<source>") to allow a destination principal ("nfs@
<destination>") to copy a file from the source to the destination.
This privilege is established on the source server before the user
principal sends a COPY_NOTIFY operation to the source server.
struct copy_from_auth_priv {
secret4 cfap_shared_secret;
netloc4 cfap_destination;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed cfap_username;
/* equal to seq_num of rpc_gss_cred_vers_3_t */
unsigned int cfap_seq_num;
};
cfp_shared_secret is a secret value the user principal generates.
copy_to_auth: A user principal is authorizing a destination
principal ("nfs@<destination>") to allow it to copy a file from
the source to the destination. This privilege is established on
the destination server before the user principal sends a COPY
operation to the destination server.
struct copy_to_auth_priv {
/* equal to cfap_shared_secret */
secret4 ctap_shared_secret;
netloc4 ctap_source;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ctap_username;
/* equal to seq_num of rpc_gss_cred_vers_3_t */
unsigned int ctap_seq_num;
};
ctap_shared_secret is a secret value the user principal generated
and was used to establish the copy_from_auth privilege with the
source principal.
copy_confirm_auth: A destination principal is confirming with the
source principal that it is authorized to copy data from the
source on behalf of the user principal. When the inter-server
copy protocol is NFSv4, or for that matter, any protocol capable
of being secured via RPCSEC_GSSv3 (i.e., any ONC RPC protocol),
this privilege is established before the file is copied from the
source to the destination.
struct copy_confirm_auth_priv {
/* equal to GSS_GetMIC() of cfap_shared_secret */
opaque ccap_shared_secret_mic<>;
/* the NFSv4 user name that the user principal maps to */
utf8str_mixed ccap_username;
/* equal to seq_num of rpc_gss_cred_vers_3_t */
unsigned int ccap_seq_num;
};
3.4.1.2.1. Establishing a Security Context
When the user principal wants to COPY a file between two servers, if
it has not established copy_from_auth and copy_to_auth privileges on
the servers, it establishes them:
o The user principal generates a secret it will share with the two
servers. This shared secret will be placed in the
cfap_shared_secret and ctap_shared_secret fields of the
appropriate privilege data types, copy_from_auth_priv and
copy_to_auth_priv.
o An instance of copy_from_auth_priv is filled in with the shared
secret, the destination server, and the NFSv4 user id of the user
principal. It will be sent with an RPCSEC_GSS3_CREATE procedure,
and so cfap_seq_num is set to the seq_num of the credential of the
RPCSEC_GSS3_CREATE procedure. Because cfap_shared_secret is a
secret, after XDR encoding copy_from_auth_priv, GSS_Wrap() (with
privacy) is invoked on copy_from_auth_priv. The
RPCSEC_GSS3_CREATE procedure's arguments are:
struct {
rpc_gss3_gss_binding *compound_binding;
rpc_gss3_chan_binding *chan_binding_mic;
rpc_gss3_assertion assertions<>;
rpc_gss3_extension extensions<>;
} rpc_gss3_create_args;
The string "copy_from_auth" is placed in assertions[0].privs. The
output of GSS_Wrap() is placed in extensions[0].data. The field
extensions[0].critical is set to TRUE. The source server calls
GSS_Unwrap() on the privilege, and verifies that the seq_num
matches the credential. It then verifies that the NFSv4 user id
being asserted matches the source server's mapping of the user
principal. If it does, the privilege is established on the source
server as: <"copy_from_auth", user id, destination>. The
successful reply to RPCSEC_GSS3_CREATE has:
struct {
opaque handle<>;
rpc_gss3_chan_binding *chan_binding_mic;
rpc_gss3_assertion granted_assertions<>;
rpc_gss3_assertion server_assertions<>;
rpc_gss3_extension extensions<>;
} rpc_gss3_create_res;
The field "handle" is the RPCSEC_GSSv3 handle that the client will
use on COPY_NOTIFY requests involving the source and destination
server. granted_assertions[0].privs will be equal to
"copy_from_auth". The server will return a GSS_Wrap() of
copy_to_auth_priv.
o An instance of copy_to_auth_priv is filled in with the shared
secret, the source server, and the NFSv4 user id. It will be sent
with an RPCSEC_GSS3_CREATE procedure, and so ctap_seq_num is set
to the seq_num of the credential of the RPCSEC_GSS3_CREATE
procedure. Because ctap_shared_secret is a secret, after XDR
encoding copy_to_auth_priv, GSS_Wrap() is invoked on
copy_to_auth_priv. The RPCSEC_GSS3_CREATE procedure's arguments
are:
struct {
rpc_gss3_gss_binding *compound_binding;
rpc_gss3_chan_binding *chan_binding_mic;
rpc_gss3_assertion assertions<>;
rpc_gss3_extension extensions<>;
} rpc_gss3_create_args;
The string "copy_to_auth" is placed in assertions[0].privs. The
output of GSS_Wrap() is placed in extensions[0].data. The field
extensions[0].critical is set to TRUE. After unwrapping,
verifying the seq_num, and the user principal to NFSv4 user ID
mapping, the destination establishes a privilege of
<"copy_to_auth", user id, source>. The successful reply to
RPCSEC_GSS3_CREATE has:
struct {
opaque handle<>;
rpc_gss3_chan_binding *chan_binding_mic;
rpc_gss3_assertion granted_assertions<>;
rpc_gss3_assertion server_assertions<>;
rpc_gss3_extension extensions<>;
} rpc_gss3_create_res;
The field "handle" is the RPCSEC_GSSv3 handle that the client will
use on COPY requests involving the source and destination server.
The field granted_assertions[0].privs will be equal to
"copy_to_auth". The server will return a GSS_Wrap() of
copy_to_auth_priv.
3.4.1.2.2. Starting a Secure Inter-Server Copy
When the client sends a COPY_NOTIFY request to the source server, it
uses the privileged "copy_from_auth" RPCSEC_GSSv3 handle.
cna_destination_server in COPY_NOTIFY MUST be the same as the name of
the destination server specified in copy_from_auth_priv. Otherwise,
COPY_NOTIFY will fail with NFS4ERR_ACCESS. The source server
verifies that the privilege <"copy_from_auth", user id, destination>
exists, and annotates it with the source filehandle, if the user
principal has read access to the source file, and if administrative
policies give the user principal and the NFS client read access to
the source file (i.e., if the ACCESS operation would grant read
access). Otherwise, COPY_NOTIFY will fail with NFS4ERR_ACCESS.
When the client sends a COPY request to the destination server, it
uses the privileged "copy_to_auth" RPCSEC_GSSv3 handle.
ca_source_server in COPY MUST be the same as the name of the source
server specified in copy_to_auth_priv. Otherwise, COPY will fail
with NFS4ERR_ACCESS. The destination server verifies that the
privilege <"copy_to_auth", user id, source> exists, and annotates it
with the source and destination filehandles. If the client has
failed to establish the "copy_to_auth" policy it will reject the
request with NFS4ERR_PARTNER_NO_AUTH.
If the client sends a OFFLOAD_REVOKE to the source server to rescind
the destination server's copy privilege, it uses the privileged
"copy_from_auth" RPCSEC_GSSv3 handle and the cra_destination_server
in OFFLOAD_REVOKE MUST be the same as the name of the destination
server specified in copy_from_auth_priv. The source server will then
delete the <"copy_from_auth", user id, destination> privilege and
fail any subsequent copy requests sent under the auspices of this
privilege from the destination server.
3.4.1.2.3. Securing ONC RPC Server-to-Server Copy Protocols
After a destination server has a "copy_to_auth" privilege established
on it, and it receives a COPY request, if it knows it will use an ONC
RPC protocol to copy data, it will establish a "copy_confirm_auth"
privilege on the source server, using nfs@<destination> as the
initiator principal, and nfs@<source> as the target principal.
The value of the field ccap_shared_secret_mic is a GSS_VerifyMIC() of
the shared secret passed in the copy_to_auth privilege. The field
ccap_username is the mapping of the user principal to an NFSv4 user
name ("user"@"domain" form), and MUST be the same as ctap_username
and cfap_username. The field ccap_seq_num is the seq_num of the
RPCSEC_GSSv3 credential used for the RPCSEC_GSS3_CREATE procedure the
destination will send to the source server to establish the
privilege.
The source server verifies the privilege, and establishes a
<"copy_confirm_auth", user id, destination> privilege. If the source
server fails to verify the privilege, the COPY operation will be
rejected with NFS4ERR_PARTNER_NO_AUTH. All subsequent ONC RPC
requests sent from the destination to copy data from the source to
the destination will use the RPCSEC_GSSv3 handle returned by the
source's RPCSEC_GSS3_CREATE response.
Note that the use of the "copy_confirm_auth" privilege accomplishes
the following:
o if a protocol like NFS is being used, with export policies, export
policies can be overridden in case the destination server as-an-
NFS-client is not authorized
o manual configuration to allow a copy relationship between the
source and destination is not needed.
If the attempt to establish a "copy_confirm_auth" privilege fails,
then when the user principal sends a COPY request to destination, the
destination server will reject it with NFS4ERR_PARTNER_NO_AUTH.
3.4.1.2.4. Securing Non ONC RPC Server-to-Server Copy Protocols
If the destination won't be using ONC RPC to copy the data, then the
source and destination are using an unspecified copy protocol. The
destination could use the shared secret and the NFSv4 user id to
prove to the source server that the user principal has authorized the
copy.
For protocols that authenticate user names with passwords (e.g., HTTP
[RFC2616] and FTP [RFC0959]), the NFSv4 user id could be used as the
user name, and an ASCII hexadecimal representation of the
RPCSEC_GSSv3 shared secret could be used as the user password or as
input into non-password authentication methods like CHAP [RFC1994].
3.4.1.3. Inter-Server Copy via ONC RPC but without RPCSEC_GSSv3
ONC RPC security flavors other than RPCSEC_GSSv3 MAY be used with the
server-side copy offload operations described in this chapter. In
particular, host-based ONC RPC security flavors such as AUTH_NONE and
AUTH_SYS MAY be used. If a host-based security flavor is used, a
minimal level of protection for the server-to-server copy protocol is
possible.
In the absence of strong security mechanisms such as RPCSEC_GSSv3, In the absence of a strong security mechanism designed for the
the challenge is how the source server and destination server purpose, the challenge is how the source server and destination
identify themselves to each other, especially in the presence of server identify themselves to each other, especially in the presence
multi-homed source and destination servers. In a multi-homed of multi-homed source and destination servers. In a multi-homed
environment, the destination server might not contact the source environment, the destination server might not contact the source
server from the same network address specified by the client in the server from the same network address specified by the client in the
COPY_NOTIFY. This can be overcome using the procedure described COPY_NOTIFY. This can be overcome using the procedure described
below. below.
When the client sends the source server the COPY_NOTIFY operation, When the client sends the source server the COPY_NOTIFY operation,
the source server may reply to the client with a list of target the source server may reply to the client with a list of target
addresses, names, and/or URLs and assign them to the unique addresses, names, and/or URLs and assign them to the unique
quadruple: <random number, source fh, user ID, destination address quadruple: <random number, source fh, user ID, destination address
Y>. If the destination uses one of these target netlocs to contact Y>. If the destination uses one of these target netlocs to contact
skipping to change at page 29, line 19 skipping to change at page 23, line 24
Provided that the random number is unpredictable and has been kept Provided that the random number is unpredictable and has been kept
secret by the parties involved, the source server will therefore know secret by the parties involved, the source server will therefore know
that these NFSv4.x operations are being issued by the destination that these NFSv4.x operations are being issued by the destination
server identified in the COPY_NOTIFY. This random number technique server identified in the COPY_NOTIFY. This random number technique
only provides initial authentication of the destination server, and only provides initial authentication of the destination server, and
cannot defend against man-in-the-middle attacks after authentication cannot defend against man-in-the-middle attacks after authentication
or an eavesdropper that observes the random number on the wire. or an eavesdropper that observes the random number on the wire.
Other secure communication techniques (e.g., IPsec) are necessary to Other secure communication techniques (e.g., IPsec) are necessary to
block these attacks. block these attacks.
3.4.1.4. Inter-Server Copy without ONC RPC and RPCSEC_GSSv3 Servers SHOULD reject COPY_NOTIFY requests that do not use RPCSEC_GSS
with privacy, thus ensuring the URL in the COPY_NOTIFY reply is
encrypted. For the same reason, clients SHOULD send COPY requests to
the destination using RPCSEC_GSS with privacy.
The same techniques as Section 3.4.1.3, using unique URLs for each 3.4.1.3. Inter-Server Copy without ONC RPC
The same techniques as Section 3.4.1.2, using unique URLs for each
destination server, can be used for other protocols (e.g., HTTP destination server, can be used for other protocols (e.g., HTTP
[RFC2616] and FTP [RFC0959]) as well. [RFC2616] and FTP [RFC0959]) as well.
4. Support for Application IO Hints 4. Support for Application IO Hints
Applications can issue client I/O hints via posix_fadvise() Applications can issue client I/O hints via posix_fadvise()
[posix_fadvise] to the NFS client. While this can help the NFS [posix_fadvise] to the NFS client. While this can help the NFS
client optimize I/O and caching for a file, it does not allow the NFS client optimize I/O and caching for a file, it does not allow the NFS
server and its exported file system to do likewise. We add an server and its exported file system to do likewise. We add an
IO_ADVISE procedure (Section 14.8) to communicate the client file IO_ADVISE procedure (Section 14.8) to communicate the client file
skipping to change at page 31, line 49 skipping to change at page 26, line 15
asynchronously via the CB_OFFLOAD operation. As a hole punch may asynchronously via the CB_OFFLOAD operation. As a hole punch may
entail deallocating data blocks, even if the filesystem supports entail deallocating data blocks, even if the filesystem supports
sparse files, it may still have to return the result via CB_OFFLOAD. sparse files, it may still have to return the result via CB_OFFLOAD.
6. Space Reservation 6. Space Reservation
6.1. Introduction 6.1. Introduction
Applications such as hypervisors want to be able to reserve space for Applications such as hypervisors want to be able to reserve space for
a file, report the amount of actual disk space a file occupies, and a file, report the amount of actual disk space a file occupies, and
freeup the backing space of a file when it is not required. In free-up the backing space of a file when it is not required. In
virtualized environments, virtual disk files are often stored on NFS virtualized environments, virtual disk files are often stored on NFS
mounted volumes. Since virtual disk files represent the hard disks mounted volumes. Since virtual disk files represent the hard disks
of virtual machines, hypervisors often have to guarantee certain of virtual machines, hypervisors often have to guarantee certain
properties for the file. properties for the file.
One such example is space reservation. When a hypervisor creates a One such example is space reservation. When a hypervisor creates a
virtual disk file, it often tries to preallocate the space for the virtual disk file, it often tries to preallocate the space for the
file so that there are no future allocation related errors during the file so that there are no future allocation related errors during the
operation of the virtual machine. Such errors prevent a virtual operation of the virtual machine. Such errors prevent a virtual
machine from continuing execution and result in downtime. machine from continuing execution and result in downtime.
skipping to change at page 38, line 15 skipping to change at page 32, line 32
8. Labeled NFS 8. Labeled NFS
8.1. Introduction 8.1. Introduction
Access control models such as Unix permissions or Access Control Access control models such as Unix permissions or Access Control
Lists are commonly referred to as Discretionary Access Control (DAC) Lists are commonly referred to as Discretionary Access Control (DAC)
models. These systems base their access decisions on user identity models. These systems base their access decisions on user identity
and resource ownership. In contrast Mandatory Access Control (MAC) and resource ownership. In contrast Mandatory Access Control (MAC)
models base their access control decisions on the label on the models base their access control decisions on the label on the
subject (usually a process) and the object it wishes to access subject (usually a process) and the object it wishes to access
[Haynes12]. These labels may contain user identity information but [Haynes13]. These labels may contain user identity information but
usually contain additional information. In DAC systems users are usually contain additional information. In DAC systems users are
free to specify the access rules for resources that they own. MAC free to specify the access rules for resources that they own. MAC
models base their security decisions on a system wide policy models base their security decisions on a system wide policy
established by an administrator or organization which the users do established by an administrator or organization which the users do
not have the ability to override. In this section, we add a MAC not have the ability to override. In this section, we add a MAC
model to NFSv4.2. model to NFSv4.2.
The first change necessary is to devise a method for transporting and The first change necessary is to devise a method for transporting and
storing security label data on NFSv4 file objects. Security labels storing security label data on NFSv4 file objects. Security labels
have several semantics that are met by NFSv4 recommended attributes have several semantics that are met by NFSv4 recommended attributes
skipping to change at page 38, line 44 skipping to change at page 33, line 14
The second change is to provide methods for the client to determine The second change is to provide methods for the client to determine
if the security label has changed. A client which needs to know if a if the security label has changed. A client which needs to know if a
label is going to change SHOULD request a delegation on that file. label is going to change SHOULD request a delegation on that file.
In order to change the security label, the server will have to recall In order to change the security label, the server will have to recall
all delegations. This will inform the client of the change. If a all delegations. This will inform the client of the change. If a
client wants to detect if the label has changed, it MAY use VERIFY client wants to detect if the label has changed, it MAY use VERIFY
and NVERIFY on FATTR4_CHANGE_SEC_LABEL to detect that the and NVERIFY on FATTR4_CHANGE_SEC_LABEL to detect that the
FATTR4_SEC_LABEL has been modified. FATTR4_SEC_LABEL has been modified.
The final change necessary is a modification to the RPC layer used in An additional useful change would be modification to the RPC layer
NFSv4 in the form of a new version of the RPCSEC_GSS [RFC2203] used in NFSv4 to allow RPC calls to carry security labels. Such
framework. In order for an NFSv4 server to apply MAC checks it must modifications are outside the scope of this document.
obtain additional information from the client. Several methods were
explored for performing this and it was decided that the best
approach was to incorporate the ability to make security attribute
assertions through the RPC mechanism. RPCSECGSSv3 [rpcsecgssv3]
outlines a method to assert additional security information such as
security labels on gss context creation and have that data bound to
all RPC requests that make use of that context.
8.2. Definitions 8.2. Definitions
Label Format Specifier (LFS): is an identifier used by the client to Label Format Specifier (LFS): is an identifier used by the client to
establish the syntactic format of the security label and the establish the syntactic format of the security label and the
semantic meaning of its components. These specifiers exist in a semantic meaning of its components. These specifiers exist in a
registry associated with documents describing the format and registry associated with documents describing the format and
semantics of the label. semantics of the label.
Label Format Registry: is the IANA registry containing all Label Format Registry: is the IANA registry containing all
skipping to change at page 41, line 33 skipping to change at page 35, line 45
support, then it is the responsibility of the security system to support, then it is the responsibility of the security system to
define the behavior for existing objects. define the behavior for existing objects.
8.3.5. Label Changes 8.3.5. Label Changes
If there are open delegations on the file belonging to client other If there are open delegations on the file belonging to client other
than the one making the label change, then the process described in than the one making the label change, then the process described in
Section 8.3.1 must be followed. In short, the delegation will be Section 8.3.1 must be followed. In short, the delegation will be
recalled, which effectively notifies the client of the change. recalled, which effectively notifies the client of the change.
As the server is always presented with the subject label from the
client, it does not necessarily need to communicate the fact that the
label has changed to the client. In the cases where the change
outright denies the client access, the client will be able to quickly
determine that there is a new label in effect.
Consider a system in which the clients enforce MAC checks and and the Consider a system in which the clients enforce MAC checks and and the
server has a very simple security system which just stores the server has a very simple security system which just stores the
labels. In this system, the MAC label check always allows access, labels. In this system, the MAC label check always allows access,
regardless of the subject label. regardless of the subject label.
The way in which MAC labels are enforced is by the client. The The way in which MAC labels are enforced is by the client. The
security policies on the client can be such that the client does not security policies on the client can be such that the client does not
have access to the file unless it has a delegation. The recall of have access to the file unless it has a delegation. The recall of
the delegation will force the client to flush any cached content of the delegation will force the client to flush any cached content of
the file. The clients could also be configured to periodically the file. The clients could also be configured to periodically
VERIFY/NVERIFY the FATTR4_CHANGE_SEC_LABEL attribute to determine VERIFY/NVERIFY the FATTR4_CHANGE_SEC_LABEL attribute to determine
when the label has changed. When a change is detected, then the when the label has changed. When a change is detected, then the
client could take the costlier action of retrieving the client could take the costlier action of retrieving the
FATTR4_SEC_LABEL. FATTR4_SEC_LABEL.
8.4. pNFS Considerations 8.4. pNFS Considerations
This section examines the issues in deploying Labeled NFS in a pNFS
community of servers.
8.4.1. MAC Label Checks
The new FATTR4_SEC_LABEL attribute is metadata information and as The new FATTR4_SEC_LABEL attribute is metadata information and as
such the DS is not aware of the value contained on the MDS. such the DS is not aware of the value contained on the MDS.
Fortunately, the NFSv4.1 protocol [RFC5661] already has provisions Fortunately, the NFSv4.1 protocol [RFC5661] already has provisions
for doing access level checks from the DS to the MDS. In order for for doing access level checks from the DS to the MDS. In order for
the DS to validate the subject label presented by the client, it the DS to validate the subject label presented by the client, it
SHOULD utilize this mechanism. SHOULD utilize this mechanism.
8.5. Discovery of Server Labeled NFS Support 8.5. Discovery of Server Labeled NFS Support
The server can easily determine that a client supports Labeled NFS The server can easily determine that a client supports Labeled NFS
when it queries for the FATTR4_SEC_LABEL label for an object. Note when it queries for the FATTR4_SEC_LABEL label for an object. The
that it cannot assume that the presence of RPCSEC_GSSv3 indicates client might need to discover which LFS the server supports.
Labeled NFS support. The client might need to discover which LFS the
server supports.
A server which supports Labeled NFS MUST allow a client with any The following compound MUST NOT be denied by any MAC label check:
subject label to retrieve the FATTR4_SEC_LABEL attribute for the root
filehandle, ROOTFH. The following compound must always succeed as
far as a MAC label check is concerned:
PUTROOTFH, GETATTR {FATTR4_SEC_LABEL} PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}
Note that the server might have imposed a security flavor on the root Note that the server might have imposed a security flavor on the root
that precludes such access. I.e., if the server requires kerberized that precludes such access. I.e., if the server requires kerberized
access and the client presents a compound with AUTH_SYS, then the access and the client presents a compound with AUTH_SYS, then the
server is allowed to return NFS4ERR_WRONGSEC in this case. But if server is allowed to return NFS4ERR_WRONGSEC in this case. But if
the client presents a correct security flavor, then the server MUST the client presents a correct security flavor, then the server MUST
return the FATTR4_SEC_LABEL attribute with the supported LFS filled return the FATTR4_SEC_LABEL attribute with the supported LFS filled
in. in.
skipping to change at page 43, line 12 skipping to change at page 37, line 7
implementing a MAC model and thus offers less protection than full implementing a MAC model and thus offers less protection than full
mode. mode.
8.6.1. Full Mode 8.6.1. Full Mode
Full mode environments consist of MAC-Functional NFSv4 servers and Full mode environments consist of MAC-Functional NFSv4 servers and
clients and may be composed of mixed MAC models and policies. The clients and may be composed of mixed MAC models and policies. The
system requires that both the client and server have an opportunity system requires that both the client and server have an opportunity
to perform an access control check based on all relevant information to perform an access control check based on all relevant information
within the network. The file object security attribute is provided within the network. The file object security attribute is provided
using the mechanism described in Section 8.3. The security attribute using the mechanism described in Section 8.3.
of the subject making the request is transported at the RPC layer
using the mechanism described in RPCSECGSSv3 [rpcsecgssv3]. Fully MAC-Functional NFSv4 servers are not possible in the absence of
RPC layer modifications to support subject label transport. However,
servers may make decisions based on the RPC credential information
available and future specifications may provide subject label
transport.
8.6.1.1. Initial Labeling and Translation 8.6.1.1. Initial Labeling and Translation
The ability to create a file is an action that a MAC model may wish The ability to create a file is an action that a MAC model may wish
to mediate. The client is given the responsibility to determine the to mediate. The client is given the responsibility to determine the
initial security attribute to be placed on a file. This allows the initial security attribute to be placed on a file. This allows the
client to make a decision as to the acceptable security attributes to client to make a decision as to the acceptable security attributes to
create a file with before sending the request to the server. Once create a file with before sending the request to the server. Once
the server receives the creation request from the client it may the server receives the creation request from the client it may
choose to evaluate if the security attribute is acceptable. choose to evaluate if the security attribute is acceptable.
skipping to change at page 43, line 49 skipping to change at page 37, line 48
8.6.1.2. Policy Enforcement 8.6.1.2. Policy Enforcement
In full mode access control decisions are made by both the clients In full mode access control decisions are made by both the clients
and servers. When a client makes a request it takes the security and servers. When a client makes a request it takes the security
attribute from the requesting process and makes an access control attribute from the requesting process and makes an access control
decision based on that attribute and the security attribute of the decision based on that attribute and the security attribute of the
object it is trying to access. If the client denies that access an object it is trying to access. If the client denies that access an
RPC call to the server is never made. If however the access is RPC call to the server is never made. If however the access is
allowed the client will make a call to the NFS server. allowed the client will make a call to the NFS server.
When the server receives the request from the client it extracts the When the server receives the request from the client it uses any
security attribute conveyed in the RPC request. The server then uses credential information conveyed in the RPC request and the attributes
this security attribute and the attribute of the object the client is of the object the client is trying to access to make an access
trying to access to make an access control decision. If the server's control decision. If the server's policy allows this access it will
policy allows this access it will fulfill the client's request, fulfill the client's request, otherwise it will return
otherwise it will return NFS4ERR_ACCESS. NFS4ERR_ACCESS.
Future protocol extensions may also allow the server to factor into
the decision a security label extracted from the RPC request.
Implementations MAY validate security attributes supplied over the Implementations MAY validate security attributes supplied over the
network to ensure that they are within a set of attributes permitted network to ensure that they are within a set of attributes permitted
from a specific peer, and if not, reject them. Note that a system from a specific peer, and if not, reject them. Note that a system
may permit a different set of attributes to be accepted from each may permit a different set of attributes to be accepted from each
peer. peer.
8.6.1.3. Limited Server 8.6.1.3. Limited Server
A Limited Server mode (see Section 3.5.2 of [Haynes12]) consists of a A Limited Server mode (see Section 3.5.2 of [Haynes13]) consists of a
server which is label aware, but does not enforce policies. Such a server which is label aware, but does not enforce policies. Such a
server will store and retrieve all object labels presented by server will store and retrieve all object labels presented by
clients, utilize the methods described in Section 8.3.5 to allow the clients, utilize the methods described in Section 8.3.5 to allow the
clients to detect changing labels,, but will not restrict access via clients to detect changing labels, but may not factor the label into
the subject label. Instead, it will expect the clients to enforce access decisions. Instead, it will expect the clients to enforce all
all such access locally. such access locally.
8.6.2. Guest Mode 8.6.2. Guest Mode
Guest mode implies that either the client or the server does not Guest mode implies that either the client or the server does not
handle labels. If the client is not Labeled NFS aware, then it will handle labels. If the client is not Labeled NFS aware, then it will
not offer subject labels to the server. The server is the only not offer subject labels to the server. The server is the only
entity enforcing policy, and may selectively provide standard NFS entity enforcing policy, and may selectively provide standard NFS
services to clients based on their authentication credentials and/or services to clients based on their authentication credentials and/or
associated network attributes (e.g., IP address, network interface). associated network attributes (e.g., IP address, network interface).
The level of trust and access extended to a client in this mode is The level of trust and access extended to a client in this mode is
skipping to change at page 48, line 17 skipping to change at page 42, line 17
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| Operation | Errors | | Operation | Errors |
+----------------+--------------------------------------------------+ +----------------+--------------------------------------------------+
| COPY | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | COPY | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, |
| | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, | | | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, | | | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, | | | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_METADATA_NOTSUPP, NFS4ERR_MOVED, |
| | NFS4ERR_NOSPC, NFS4ERR_OFFLOAD_DENIED, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE, | | | NFS4ERR_OFFLOAD_DENIED, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_OPENMODE, NFS4ERR_OP_NOT_IN_SESSION, |
| | NFS4ERR_PARTNER_NO_AUTH, | | | NFS4ERR_PARTNER_NO_AUTH, |
| | NFS4ERR_PARTNER_NOTSUPP, NFS4ERR_PNFS_IO_HOLE, | | | NFS4ERR_PARTNER_NOTSUPP, NFS4ERR_PNFS_IO_HOLE, |
| | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_PNFS_NO_LAYOUT, NFS4ERR_REP_TOO_BIG, |
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, |
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_RETRY_UNCACHED_REP, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, | | | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE | | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONG_TYPE |
| COPY_NOTIFY | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | COPY_NOTIFY | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
skipping to change at page 54, line 29 skipping to change at page 48, line 29
guaranteed that the server will accept a label that is sized guaranteed that the server will accept a label that is sized
correctly. By both client and server being part of a specific MAC correctly. By both client and server being part of a specific MAC
model, the client will be aware of the size. model, the client will be aware of the size.
If a server supports sec_label, then it MUST also support If a server supports sec_label, then it MUST also support
change_sec_label. Any modification to sec_label MUST modify the change_sec_label. Any modification to sec_label MUST modify the
value for change_sec_label. value for change_sec_label.
12.2.3. Attribute 81: change_sec_label 12.2.3. Attribute 81: change_sec_label
struct change_sec_label4 {
uint64_t csl_major;
uint64_t csl_minor;
};
The change_sec_label attribute is a read-only attribute per file. If The change_sec_label attribute is a read-only attribute per file. If
the value of sec_label for a file is not the same at two disparate the value of sec_label for a file is not the same at two disparate
times then the values of change_sec_label at those times MUST be times then the values of change_sec_label at those times MUST be
different as well. The value of change_sec_label MAY change at other different as well. The value of change_sec_label MAY change at other
times as well, but this should be rare, as that will require the times as well, but this should be rare, as that will require the
client to abort any operation in progress, re-read the label, and client to abort any operation in progress, re-read the label, and
retry the operation. As the sec_label is not bounded by size, this retry the operation. As the sec_label is not bounded by size, this
attribute allows for VERIFY and NVERIFY to quickly determine if the attribute allows for VERIFY and NVERIFY to quickly determine if the
sec_label has been modified. sec_label has been modified.
skipping to change at page 55, line 39 skipping to change at page 49, line 33
space_freed gives the number of bytes freed if the file is deleted. space_freed gives the number of bytes freed if the file is deleted.
This attribute is read only and is of type length4. It is a per file This attribute is read only and is of type length4. It is a per file
attribute. attribute.
13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL 13. Operations: REQUIRED, RECOMMENDED, or OPTIONAL
The following tables summarize the operations of the NFSv4.2 protocol The following tables summarize the operations of the NFSv4.2 protocol
and the corresponding designation of REQUIRED, RECOMMENDED, and and the corresponding designation of REQUIRED, RECOMMENDED, and
OPTIONAL to implement or either OBSOLESCENT or MUST NOT implement. OPTIONAL to implement or either OBSOLESCENT or MUST NOT implement.
The designation of OBSOLESCENT for those operations which are defined The designation of OBSOLESCENT is reserved for those operations which
in either NFSv4.0 or NFSv4.1 and are intended to be classified as are defined in either NFSv4.0 or NFSv4.1 and are intended to be
MUST NOT be implemented in NFSv4.3. The designation of MUST NOT classified as MUST NOT be implemented in NFSv4.3. The designation of
implement is reserved for those operations that were defined in MUST NOT implement is reserved for those operations that were defined
either NFSv4.0 or NFSV4.1 and MUST NOT be implemented in NFSv4.2. in either NFSv4.0 or NFSV4.1 and MUST NOT be implemented in NFSv4.2.
For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation
for operations sent by the client is for the server implementation. for operations sent by the client is for the server implementation.
The client is generally required to implement the operations needed The client is generally required to implement the operations needed
for the operating environment for which it serves. For example, a for the operating environment for which it serves. For example, a
read-only NFSv4.2 client would have no need to implement the WRITE read-only NFSv4.2 client would have no need to implement the WRITE
operation and is not required to do so. operation and is not required to do so.
The REQUIRED or OPTIONAL designation for callback operations sent by The REQUIRED or OPTIONAL designation for callback operations sent by
the server is for both the client and server. Generally, the client the server is for both the client and server. Generally, the client
skipping to change at page 59, line 35 skipping to change at page 53, line 11
| CB_WANTS_CANCELLED | OPT | FDELG, DDELG, pNFS | | CB_WANTS_CANCELLED | OPT | FDELG, DDELG, pNFS |
| | | (REQ) | | | | (REQ) |
+-------------------------+-------------------+---------------------+ +-------------------------+-------------------+---------------------+
14. NFSv4.2 Operations 14. NFSv4.2 Operations
14.1. Operation 59: COPY - Initiate a server-side copy 14.1. Operation 59: COPY - Initiate a server-side copy
14.1.1. ARGUMENT 14.1.1. ARGUMENT
const COPY4_GUARDED = 0x00000001;
const COPY4_METADATA = 0x00000002;
struct COPY4args { struct COPY4args {
/* SAVED_FH: source file */ /* SAVED_FH: source file */
/* CURRENT_FH: destination file or */ /* CURRENT_FH: destination file */
/* directory */
stateid4 ca_src_stateid; stateid4 ca_src_stateid;
stateid4 ca_dst_stateid; stateid4 ca_dst_stateid;
offset4 ca_src_offset; offset4 ca_src_offset;
offset4 ca_dst_offset; offset4 ca_dst_offset;
length4 ca_count; length4 ca_count;
uint32_t ca_flags;
component4 ca_destination;
netloc4 ca_source_server<>; netloc4 ca_source_server<>;
}; };
14.1.2. RESULT 14.1.2. RESULT
union COPY4res switch (nfsstat4 cr_status) { union COPY4res switch (nfsstat4 cr_status) {
case NFS4_OK: case NFS4_OK:
write_response4 resok4; write_response4 resok4;
default: default:
length4 cr_bytes_copied; length4 cr_bytes_copied;
}; };
skipping to change at page 60, line 22 skipping to change at page 53, line 37
default: default:
length4 cr_bytes_copied; length4 cr_bytes_copied;
}; };
14.1.3. DESCRIPTION 14.1.3. DESCRIPTION
The COPY operation is used for both intra-server and inter-server The COPY operation is used for both intra-server and inter-server
copies. In both cases, the COPY is always sent from the client to copies. In both cases, the COPY is always sent from the client to
the destination server of the file copy. The COPY operation requests the destination server of the file copy. The COPY operation requests
that a file be copied from the location specified by the SAVED_FH that a file be copied from the location specified by the SAVED_FH
value to the location specified by the combination of CURRENT_FH and value to the location specified by the CURRENT_FH.
ca_destination.
The SAVED_FH must be a regular file. If SAVED_FH is not a regular The SAVED_FH must be a regular file. If SAVED_FH is not a regular
file, the operation MUST fail and return NFS4ERR_WRONG_TYPE. file, the operation MUST fail and return NFS4ERR_WRONG_TYPE.
In order to set SAVED_FH to the source file handle, the compound In order to set SAVED_FH to the source file handle, the compound
procedure requesting the COPY will include a sub-sequence of procedure requesting the COPY will include a sub-sequence of
operations such as operations such as
PUTFH source-fh PUTFH source-fh
SAVEFH SAVEFH
skipping to change at page 61, line 9 skipping to change at page 54, line 23
context of the operation referencing them and an NFS4ERR_STALE error context of the operation referencing them and an NFS4ERR_STALE error
returned for an invalid file handle at that point. returned for an invalid file handle at that point.
For an intra-server copy, both the ca_src_stateid and ca_dst_stateid For an intra-server copy, both the ca_src_stateid and ca_dst_stateid
MUST refer to either open or locking states provided earlier by the MUST refer to either open or locking states provided earlier by the
server. If either stateid is invalid, then the operation MUST fail. server. If either stateid is invalid, then the operation MUST fail.
If the request is for a inter-server copy, then the ca_src_stateid If the request is for a inter-server copy, then the ca_src_stateid
can be ignored. If ca_dst_stateid is invalid, then the operation can be ignored. If ca_dst_stateid is invalid, then the operation
MUST fail. MUST fail.
The CURRENT_FH and ca_destination together specify the destination of The CURRENT_FH specifies the destination of the copy operation. The
the copy operation. If ca_destination is of 0 (zero) length, then CURRENT_FH MUST be a regular file and not a directory. Note, the
CURRENT_FH specifies the target file. In this case, CURRENT_FH MUST file MUST exist before the COPY operation begins. It is the
be a regular file and not a directory. If ca_destination is not of 0 responsibility of the client to create the file if necessary,
(zero) length, the ca_destination argument specifies the file name to regardless of the actual copy protocol used. If the file cannot be
which the data will be copied within the directory identified by
CURRENT_FH. In this case, CURRENT_FH MUST be a directory and not a
regular file.
If the file named by ca_destination does not exist and the operation
completes successfully, the file will be visible in the file system
namespace. If the file does not exist and the operation fails, the
file MAY be visible in the file system namespace depending on when
the failure occurs and on the implementation of the NFS server
receiving the COPY operation. If the ca_destination name cannot be
created in the destination file system (due to file name created in the destination file system (due to file name
restrictions, such as case or length), the operation MUST fail. restrictions, such as case or length), the COPY operation MUST NOT be
called.
The ca_src_offset is the offset within the source file from which the The ca_src_offset is the offset within the source file from which the
data will be read, the ca_dst_offset is the offset within the data will be read, the ca_dst_offset is the offset within the
destination file to which the data will be written, and the ca_count destination file to which the data will be written, and the ca_count
is the number of bytes that will be copied. An offset of 0 (zero) is the number of bytes that will be copied. An offset of 0 (zero)
specifies the start of the file. A count of 0 (zero) requests that specifies the start of the file. A count of 0 (zero) requests that
all bytes from ca_src_offset through EOF be copied to the all bytes from ca_src_offset through EOF be copied to the
destination. If concurrent modifications to the source file overlap destination. If concurrent modifications to the source file overlap
with the source file region being copied, the data copied may include with the source file region being copied, the data copied may include
all, some, or none of the modifications. The client can use standard all, some, or none of the modifications. The client can use standard
skipping to change at page 62, line 5 skipping to change at page 55, line 9
value or preventing modification of the source file as mentioned value or preventing modification of the source file as mentioned
above). above).
If the source offset or the source offset plus count is greater than If the source offset or the source offset plus count is greater than
or equal to the size of the source file, the operation will fail with or equal to the size of the source file, the operation will fail with
NFS4ERR_INVAL. The destination offset or destination offset plus NFS4ERR_INVAL. The destination offset or destination offset plus
count may be greater than the size of the destination file. This count may be greater than the size of the destination file. This
allows for the client to issue parallel copies to implement allows for the client to issue parallel copies to implement
operations such as "cat file1 file2 file3 file4 > dest". operations such as "cat file1 file2 file3 file4 > dest".
If the destination file is created as a result of this command, the
destination file's size will be equal to the number of bytes
successfully copied. If the destination file already existed, the
destination file's size may increase as a result of this operation
(e.g. if ca_dst_offset plus ca_count is greater than the
destination's initial size).
If the ca_source_server list is specified, then this is an inter- If the ca_source_server list is specified, then this is an inter-
server copy operation and the source file is on a remote server. The server copy operation and the source file is on a remote server. The
client is expected to have previously issued a successful COPY_NOTIFY client is expected to have previously issued a successful COPY_NOTIFY
request to the remote source server. The ca_source_server list MUST request to the remote source server. The ca_source_server list MUST
be the same as the COPY_NOTIFY response's cnr_source_server list. If be the same as the COPY_NOTIFY response's cnr_source_server list. If
the client includes the entries from the COPY_NOTIFY response's the client includes the entries from the COPY_NOTIFY response's
cnr_source_server list in the ca_source_server list, the source cnr_source_server list in the ca_source_server list, the source
server can indicate a specific copy protocol for the destination server can indicate a specific copy protocol for the destination
server to use by returning a URL, which specifies both a protocol server to use by returning a URL, which specifies both a protocol
service and server name. Server-to-server copy protocol service and server name. Server-to-server copy protocol
considerations are described in Section 3.2.5 and Section 3.4.1. considerations are described in Section 3.2.5 and Section 3.4.1.
The ca_flags argument allows the copy operation to be customized in The copying of any and all attributes on the source file is the
the following ways using the guarded flag (COPY4_GUARDED) and the responsibility of both the client and the copy protocol. Any
metadata flag (COPY4_METADATA). attribute which is both exposed via the NFS protocol on the source
file and set SHOULD be copied to the destination file. Any attribute
If the guarded flag is set and the destination exists on the server, supported by the destination server that is not set on the source
this operation will fail with NFS4ERR_EXIST. file SHOULD be left unset. If the client cannot copy an attribute
from the source to destination, it MAY fail the copy transaction.
If the guarded flag is not set and the destination exists on the
server, the behavior is implementation dependent.
If the metadata flag is set and the client is requesting a whole file
copy (i.e., ca_count is 0 (zero)), a subset of the destination file's
attributes MUST be the same as the source file's corresponding
attributes and a subset of the destination file's attributes SHOULD
be the same as the source file's corresponding attributes. The
attributes in the MUST and SHOULD copy subsets will be defined for
each NFS version.
For NFSv4.2, Table 5 and Table 6 list the REQUIRED and RECOMMENDED
attributes respectively. In the "Copy to destination file?" column,
a "MUST" indicates that the attribute is part of the MUST copy set.
A "SHOULD" indicates that the attribute is part of the SHOULD copy
set. A "no" indicates that the attribute MUST NOT be copied.
REQUIRED attributes
+--------------------+----+---------------------------+
| Name | Id | Copy to destination file? |
+--------------------+----+---------------------------+
| supported_attrs | 0 | no |
| type | 1 | MUST |
| fh_expire_type | 2 | no |
| change | 3 | SHOULD |
| size | 4 | MUST |
| link_support | 5 | no |
| symlink_support | 6 | no |
| named_attr | 7 | no |
| fsid | 8 | no |
| unique_handles | 9 | no |
| lease_time | 10 | no |
| rdattr_error | 11 | no |
| filehandle | 19 | no |
| suppattr_exclcreat | 75 | no |
+--------------------+----+---------------------------+
Table 5
RECOMMENDED attributes
+--------------------+----+---------------------------+
| Name | Id | Copy to destination file? |
+--------------------+----+---------------------------+
| acl | 12 | MUST |
| aclsupport | 13 | no |
| archive | 14 | no |
| cansettime | 15 | no |
| case_insensitive | 16 | no |
| case_preserving | 17 | no |
| change_attr_type | 79 | no |
| change_policy | 60 | no |
| chown_restricted | 18 | MUST |
| dacl | 58 | MUST |
| dir_notif_delay | 56 | no |
| dirent_notif_delay | 57 | no |
| fileid | 20 | no |
| files_avail | 21 | no |
| files_free | 22 | no |
| files_total | 23 | no |
| fs_charset_cap | 76 | no |
| fs_layout_type | 62 | no |
| fs_locations | 24 | no |
| fs_locations_info | 67 | no |
| fs_status | 61 | no |
| hidden | 25 | MUST |
| homogeneous | 26 | no |
| layout_alignment | 66 | no |
| layout_blksize | 65 | no |
| layout_hint | 63 | no |
| layout_type | 64 | no |
| maxfilesize | 27 | no |
| maxlink | 28 | no |
| maxname | 29 | no |
| maxread | 30 | no |
| maxwrite | 31 | no |
| mdsthreshold | 68 | no |
| mimetype | 32 | MUST |
| mode | 33 | MUST |
| mode_set_masked | 74 | no |
| mounted_on_fileid | 55 | no |
| no_trunc | 34 | no |
| numlinks | 35 | no |
| owner | 36 | MUST |
| owner_group | 37 | MUST |
| quota_avail_hard | 38 | no |
| quota_avail_soft | 39 | no |
| quota_used | 40 | no |
| rawdev | 41 | no |
| retentevt_get | 71 | MUST |
| retentevt_set | 72 | no |
| retention_get | 69 | MUST |
| retention_hold | 73 | MUST |
| retention_set | 70 | no |
| sacl | 59 | MUST |
| sec_label | 80 | MUST |
| space_avail | 42 | no |
| space_free | 43 | no |
| space_freed | 78 | no |
| space_reserved | 77 | MUST |
| space_total | 44 | no |
| space_used | 45 | no |
| system | 46 | MUST |
| time_access | 47 | MUST |
| time_access_set | 48 | no |
| time_backup | 49 | no |
| time_create | 50 | MUST |
| time_delta | 51 | no |
| time_metadata | 52 | SHOULD |
| time_modify | 53 | MUST |
| time_modify_set | 54 | no |
+--------------------+----+---------------------------+
Table 6
[NOTE: The source file's attribute values will take precedence over
any attribute values inherited by the destination file.]
In the case of an inter-server copy or an intra-server copy between
file systems, the attributes supported for the source file and
destination file could be different. By definition,the REQUIRED
attributes will be supported in all cases. If the metadata flag is
set and the source file has a RECOMMENDED attribute that is not
supported for the destination file, the copy MUST fail with
NFS4ERR_ATTRNOTSUPP.
Any attribute supported by the destination server that is not set on
the source file SHOULD be left unset.
Metadata attributes not exposed via the NFS protocol SHOULD be copied Metadata attributes not exposed via the NFS protocol SHOULD be copied
to the destination file where appropriate. to the destination file where appropriate via the copy protocol.
Note that if the copy protocol is NFSv4.x, then these attributes will
be lost.
The destination file's named attributes are not duplicated from the The destination file's named attributes are not duplicated from the
source file. After the copy process completes, the client MAY source file. After the copy process completes, the client MAY
attempt to duplicate named attributes using standard NFSv4 attempt to duplicate named attributes using standard NFSv4
operations. However, the destination file's named attribute operations. However, the destination file's named attribute
capabilities MAY be different from the source file's named attribute capabilities MAY be different from the source file's named attribute
capabilities. capabilities.
If the metadata flag is not set and the client is requesting a whole
file copy (i.e., ca_count is 0 (zero)), the destination file's
metadata is implementation dependent.
If the client is requesting a partial file copy (i.e., ca_count is
not 0 (zero)), the client SHOULD NOT set the metadata flag and the
server MUST ignore the metadata flag.
If the operation does not result in an immediate failure, the server If the operation does not result in an immediate failure, the server
will return NFS4_OK, and the CURRENT_FH will remain the destination's will return NFS4_OK, and the CURRENT_FH will remain the destination's
filehandle. filehandle.
If an immediate failure does occur, cr_bytes_copied will be set to If an immediate failure does occur, cr_bytes_copied will be set to
the number of bytes copied to the destination file before the error the number of bytes copied to the destination file before the error
occurred. The cr_bytes_copied value indicates the number of bytes occurred. The cr_bytes_copied value indicates the number of bytes
copied but not which specific bytes have been copied. copied but not which specific bytes have been copied.
A return of NFS4_OK indicates that either the operation is complete A return of NFS4_OK indicates that either the operation is complete
skipping to change at page 76, line 45 skipping to change at page 66, line 45
|<------------------------------------/| the file |<------------------------------------/| the file
| | | |
| | | |
Figure 6: An asynchronous WRITE_PLUS. Figure 6: An asynchronous WRITE_PLUS.
When CB_OFFLOAD informs the client of the successful WRITE_PLUS, the When CB_OFFLOAD informs the client of the successful WRITE_PLUS, the
write_response4 embedded in the operation will provide the necessary write_response4 embedded in the operation will provide the necessary
information that a synchronous WRITE_PLUS would have provided. information that a synchronous WRITE_PLUS would have provided.
Regardelss of whether the operation is asynchronous or synchronous, Regardless of whether the operation is asynchronous or synchronous,
it MUST still support the COMMIT operation semantics as outlined in it MUST still support the COMMIT operation semantics as outlined in
Section 18.3 of [RFC5661]. I.e., COMMIT works on one or more WRITE Section 18.3 of [RFC5661]. I.e., COMMIT works on one or more WRITE
operations and the WRITE_PLUS operation can appear as several WRITE operations and the WRITE_PLUS operation can appear as several WRITE
operations to the server. The client can use locking operations to operations to the server. The client can use locking operations to
control the behavior on the server with respect to a long running control the behavior on the server with respect to long running
asynchornous write operations. asynchronous write operations.
14.8. Operation 67: IO_ADVISE - Application I/O access pattern hints 14.8. Operation 67: IO_ADVISE - Application I/O access pattern hints
14.8.1. ARGUMENT 14.8.1. ARGUMENT
enum IO_ADVISE_type4 { enum IO_ADVISE_type4 {
IO_ADVISE4_NORMAL = 0, IO_ADVISE4_NORMAL = 0,
IO_ADVISE4_SEQUENTIAL = 1, IO_ADVISE4_SEQUENTIAL = 1,
IO_ADVISE4_SEQUENTIAL_BACKWARDS = 2, IO_ADVISE4_SEQUENTIAL_BACKWARDS = 2,
IO_ADVISE4_RANDOM = 3, IO_ADVISE4_RANDOM = 3,
skipping to change at page 89, line 26 skipping to change at page 79, line 26
| Byte-Range | Contents | | Byte-Range | Contents |
+-------------+----------+ +-------------+----------+
| 0-15999 | Hole | | 0-15999 | Hole |
| 16K-31999 | Non-Zero | | 16K-31999 | Non-Zero |
| 32K-255999 | Hole | | 32K-255999 | Hole |
| 256K-287999 | Non-Zero | | 256K-287999 | Non-Zero |
| 288K-353999 | Hole | | 288K-353999 | Hole |
| 354K-417999 | Non-Zero | | 354K-417999 | Non-Zero |
+-------------+----------+ +-------------+----------+
Table 7 Table 5
Under the given circumstances, if a client was to read from the file Under the given circumstances, if a client was to read from the file
with a max read size of 64K, the following will be the results for with a max read size of 64K, the following will be the results for
the given READ_PLUS calls. This assumes the client has already the given READ_PLUS calls. This assumes the client has already
opened the file, acquired a valid stateid ('s' in the example), and opened the file, acquired a valid stateid ('s' in the example), and
just needs to issue READ_PLUS requests. just needs to issue READ_PLUS requests.
1. READ_PLUS(s, 0, 64K) --> NFS_OK, eof = false, <data[0,32K], 1. READ_PLUS(s, 0, 64K) --> NFS_OK, eof = false, <data[0,32K],
hole[32K,224K]>. Since the first hole is less than the server's hole[32K,224K]>. Since the first hole is less than the server's
Hole Threshhold, the first 32K of the file is returned as data Hole Threshhold, the first 32K of the file is returned as data
skipping to change at page 92, line 33 skipping to change at page 82, line 33
1. the COPY operation 1. the COPY operation
2. the WRITE_PLUS operation and any arm of the discriminated union 2. the WRITE_PLUS operation and any arm of the discriminated union
other than NFS4_CONTENT_DATA other than NFS4_CONTENT_DATA
then the client is REQUIRED to support the CB_OFFLOAD operation. then the client is REQUIRED to support the CB_OFFLOAD operation.
There is a potential race between the reply to the original There is a potential race between the reply to the original
transaction on the forechannel and the CB_OFFLOAD callback on the transaction on the forechannel and the CB_OFFLOAD callback on the
backchannel. Sections 2.10.6.3 and 20.9.3 in [RFC5661] describes how backchannel. Sections 2.10.6.3 and 20.9.3 of [RFC5661] describe how
to handle this type of issue. to handle this type of issue.
15.1.3.1. Server-side Copy 15.1.3.1. Server-side Copy
CB_OFFLOAD is used for both intra- and inter-server asynchronous CB_OFFLOAD is used for both intra- and inter-server asynchronous
copies. This operation is sent by the destination server to the copies. This operation is sent by the destination server to the
client in a CB_COMPOUND request. Upon success, the client in a CB_COMPOUND request. Upon success, the
coa_resok4.wr_count presents the total number of bytes copied. coa_resok4.wr_count presents the total number of bytes copied.
15.1.3.2. WRITE_PLUS 15.1.3.2. WRITE_PLUS
skipping to change at page 93, line 13 skipping to change at page 83, line 13
This section uses terms that are defined in [RFC5226]. This section uses terms that are defined in [RFC5226].
17. References 17. References
17.1. Normative References 17.1. Normative References
[4.2xdr] Haynes, T., "Network File System (NFS) Version 4 Minor [4.2xdr] Haynes, T., "Network File System (NFS) Version 4 Minor
Version 2 External Data Representation Standard (XDR) Version 2 External Data Representation Standard (XDR)
Description", March 2013. Description", March 2013.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010. RFC 5661, January 2010.
[RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based [RFC5664] Halevy, B., Welch, B., and J. Zelenka, "Object-Based
Parallel NFS (pNFS) Operations", RFC 5664, January 2010. Parallel NFS (pNFS) Operations", RFC 5664, January 2010.
[posix_fadvise] [posix_fadvise]
The Open Group, "Section 'posix_fadvise()' of System The Open Group, "Section 'posix_fadvise()' of System
Interfaces of The Open Group Base Specifications Issue 6, Interfaces of The Open Group Base Specifications Issue 6,
IEEE Std 1003.1, 2004 Edition", 2004. IEEE Std 1003.1, 2004 Edition", 2004.
[rpcsecgssv3]
Haynes, T. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-williams-rpcsecgssv3 (work in
progress), 2011.
17.2. Informative References 17.2. Informative References
[Ashdown08] [Ashdown08]
Ashdown, L., "Chapter 15, Validating Database Files and Ashdown, L., "Chapter 15, Validating Database Files and
Backups, of Oracle Database Backup and Recovery User's Backups, of Oracle Database Backup and Recovery User's
Guide 11g Release 1 (11.1)", August 2008. Guide 11g Release 1 (11.1)", August 2008.
[Baira08] Bairavasundaram, L., Goodson, G., Schroeder, B., Arpaci- [Baira08] Bairavasundaram, L., Goodson, G., Schroeder, B., Arpaci-
Dusseau, A., and R. Arpaci-Dusseau, "An Analysis of Data Dusseau, A., and R. Arpaci-Dusseau, "An Analysis of Data
Corruption in the Storage Stack", Proceedings of the 6th Corruption in the Storage Stack", Proceedings of the 6th
skipping to change at page 94, line 13 skipping to change at page 84, line 5
Naik, "Administration Protocol for Federated Filesystems", Naik, "Administration Protocol for Federated Filesystems",
draft-ietf-nfsv4-federated-fs-admin (Work In Progress), draft-ietf-nfsv4-federated-fs-admin (Work In Progress),
2010. 2010.
[FEDFS-NSDB] [FEDFS-NSDB]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "NSDB Protocol for Federated Filesystems", Naik, "NSDB Protocol for Federated Filesystems",
draft-ietf-nfsv4-federated-fs-protocol (Work In Progress), draft-ietf-nfsv4-federated-fs-protocol (Work In Progress),
2010. 2010.
[Haynes12] [Haynes13]
Haynes, T., "Requirements for Labeled NFS", Haynes, T., "Requirements for Labeled NFS",
draft-ietf-nfsv4-labreqs-03 (work in progress). draft-ietf-nfsv4-labreqs-04 (work in progress), 2013.
[I-D.ietf-nfsv4-rfc3530bis] [I-D.ietf-nfsv4-rfc3530bis]
Haynes, T. and D. Noveck, "Network File System (NFS) Haynes, T. and D. Noveck, "Network File System (NFS)
version 4 Protocol", draft-ietf-nfsv4-rfc3530bis-25 (Work version 4 Protocol", draft-ietf-nfsv4-rfc3530bis-25 (Work
In Progress), February 2013. In Progress), February 2013.
[IESG08] ISEG, "IESG Processing of RFC Errata for the IETF Stream", [IESG08] ISEG, "IESG Processing of RFC Errata for the IETF Stream",
2008. 2008.
[MLS] "Section 46.6. Multi-Level Security (MLS) of Deployment [MLS] "Section 46.6. Multi-Level Security (MLS) of Deployment
skipping to change at page 94, line 42 skipping to change at page 84, line 34
[Quigley11] [Quigley11]
Quigley, D. and J. Lu, "Registry Specification for MAC Quigley, D. and J. Lu, "Registry Specification for MAC
Security Label Formats", Security Label Formats",
draft-quigley-label-format-registry (work in progress), draft-quigley-label-format-registry (work in progress),
2011. 2011.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985. STD 9, RFC 959, October 1985.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
RFC 4506, May 2006. RFC 4506, May 2006.
skipping to change at page 95, line 49 skipping to change at page 85, line 37
Hildebrand and Marc Eshel. Valuable input and advice was received Hildebrand and Marc Eshel. Valuable input and advice was received
from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and from Sorin Faibish, Bruce Fields, Benny Halevy, Trond Myklebust, and
Richard Scheffenegger. Richard Scheffenegger.
For the Application IO Hints, the original draft was by Dean For the Application IO Hints, the original draft was by Dean
Hildebrand, Mike Eisler, Trond Myklebust, and Sam Falkner. Some Hildebrand, Mike Eisler, Trond Myklebust, and Sam Falkner. Some
early reviewers included Benny Halevy and Pranoop Erasani. early reviewers included Benny Halevy and Pranoop Erasani.
For Labeled NFS, the original draft was by David Quigley, James For Labeled NFS, the original draft was by David Quigley, James
Morris, Jarret Lu, and Tom Haynes. Peter Staubach, Trond Myklebust, Morris, Jarret Lu, and Tom Haynes. Peter Staubach, Trond Myklebust,
Stephen Smalley, Sorrin Faibish, Nico Williams, and David Black also Stephen Smalley, Sorin Faibish, Nico Williams, and David Black also
contributed in the final push to get this accepted. contributed in the final push to get this accepted.
During the review process, Talia Reyes-Ortiz helped the sessions run During the review process, Talia Reyes-Ortiz helped the sessions run
smoothly. While many people contributed here and there, the core smoothly. While many people contributed here and there, the core
reviewers were Andy Adamson, Pranoop Erasani, Bruce Fields, Chuck reviewers were Andy Adamson, Pranoop Erasani, Bruce Fields, Chuck
Lever, Trond Myklebust, David Noveck, Peter Staubach, and Mike Lever, Trond Myklebust, David Noveck, Peter Staubach, and Mike
Kupfer. Kupfer.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
skipping to change at page 96, line 24 skipping to change at page 86, line 11
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document] RFC number of this document]
Author's Address Author's Address
Thomas Haynes (editor) Thomas Haynes (editor)
NetApp NetApp
9110 E 66th St 495 E Java Dr
Tulsa, OK 74133 Sunnyvale, CA 95054
USA USA
Phone: +1 918 307 1415 Phone: +1 408 419 3018
Email: thomas@netapp.com Email: thomas@netapp.com
URI: http://www.tulsalabs.com
 End of changes. 64 change blocks. 
629 lines changed or deleted 170 lines changed or added

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