draft-ietf-nfsv4-minorversion2-03.txt   draft-ietf-nfsv4-minorversion2-04.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Editor Internet-Draft Editor
Intended status: Standards Track August 14, 2011 Intended status: Standards Track August 24, 2011
Expires: February 15, 2012 Expires: February 25, 2012
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-03.txt draft-ietf-nfsv4-minorversion2-04.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, Space Reservations, and Support for Sparse Files. Copy, Space Reservations, and Support for Sparse Files.
Requirements Language Requirements Language
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 February 15, 2012. This Internet-Draft will expire on February 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. The NFS Version 4 Minor Version 2 Protocol . . . . . . . . 6 1.1. The NFS Version 4 Minor Version 2 Protocol . . . . . . . . 6
1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 6 1.2. Scope of This Document . . . . . . . . . . . . . . . . . . 6
1.3. NFSv4.2 Goals . . . . . . . . . . . . . . . . . . . . . . 6 1.3. NFSv4.2 Goals . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Overview of NFSv4.2 Features . . . . . . . . . . . . . . . 6 1.4. Overview of NFSv4.2 Features . . . . . . . . . . . . . . . 6
1.5. Differences from NFSv4.1 . . . . . . . . . . . . . . . . . 6 1.5. Differences from NFSv4.1 . . . . . . . . . . . . . . . . . 6
2. pNFS LAYOUTRETURN Error Handling . . . . . . . . . . . . . . . 6 2. pNFS LAYOUTRETURN Error Handling . . . . . . . . . . . . . . . 6
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 7 2.2. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 7
2.2.1. ARGUMENT . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. ARGUMENT . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. RESULT . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2. RESULT . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3. DESCRIPTION . . . . . . . . . . . . . . . . . . . . . 7 2.2.3. DESCRIPTION . . . . . . . . . . . . . . . . . . . . . 8
2.2.4. IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . 8 2.2.4. IMPLEMENTATION . . . . . . . . . . . . . . . . . . . . 8
3. Sharing change attribute implementation details with NFSv4 3. Sharing change attribute implementation details with NFSv4
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Definition of the 'change_attr_type' per-file system
3.3. Definition of the 'change_attr_type' per-file system
attribute . . . . . . . . . . . . . . . . . . . . . . . . 10 attribute . . . . . . . . . . . . . . . . . . . . . . . . 10
4. NFS Server-side Copy . . . . . . . . . . . . . . . . . . . . . 11 4. NFS Server-side Copy . . . . . . . . . . . . . . . . . . . . . 11
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 12 4.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Intra-Server Copy . . . . . . . . . . . . . . . . . . 14 4.2.1. Intra-Server Copy . . . . . . . . . . . . . . . . . . 14
4.2.2. Inter-Server Copy . . . . . . . . . . . . . . . . . . 15 4.2.2. Inter-Server Copy . . . . . . . . . . . . . . . . . . 15
4.2.3. Server-to-Server Copy Protocol . . . . . . . . . . . . 18 4.2.3. Server-to-Server Copy Protocol . . . . . . . . . . . . 18
4.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1. netloc4 - Network Locations . . . . . . . . . . . . . 20 4.3.1. netloc4 - Network Locations . . . . . . . . . . . . . 20
4.3.2. Copy Offload Stateids . . . . . . . . . . . . . . . . 21 4.3.2. Copy Offload Stateids . . . . . . . . . . . . . . . . 21
skipping to change at page 4, line 27 skipping to change at page 4, line 26
7.5.5. READ_PLUS with Sparse Files Example . . . . . . . . . 47 7.5.5. READ_PLUS with Sparse Files Example . . . . . . . . . 47
7.6. Related Work . . . . . . . . . . . . . . . . . . . . . . . 48 7.6. Related Work . . . . . . . . . . . . . . . . . . . . . . . 48
7.7. Other Proposed Designs . . . . . . . . . . . . . . . . . . 48 7.7. Other Proposed Designs . . . . . . . . . . . . . . . . . . 48
7.7.1. Multi-Data Server Hole Information . . . . . . . . . . 48 7.7.1. Multi-Data Server Hole Information . . . . . . . . . . 48
7.7.2. Data Result Array . . . . . . . . . . . . . . . . . . 49 7.7.2. Data Result Array . . . . . . . . . . . . . . . . . . 49
7.7.3. User-Defined Sparse Mask . . . . . . . . . . . . . . . 49 7.7.3. User-Defined Sparse Mask . . . . . . . . . . . . . . . 49
7.7.4. Allocated flag . . . . . . . . . . . . . . . . . . . . 49 7.7.4. Allocated flag . . . . . . . . . . . . . . . . . . . . 49
7.7.5. Dense and Sparse pNFS File Layouts . . . . . . . . . . 50 7.7.5. Dense and Sparse pNFS File Layouts . . . . . . . . . . 50
8. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 50 8. Labeled NFS . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 50 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 50
8.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 52 8.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 51
8.3. MAC Security Attribute . . . . . . . . . . . . . . . . . . 52 8.3. MAC Security Attribute . . . . . . . . . . . . . . . . . . 51
8.3.1. Interpreting FATTR4_SEC_LABEL . . . . . . . . . . . . 53 8.3.1. Interpreting FATTR4_SEC_LABEL . . . . . . . . . . . . 52
8.3.2. Delegations . . . . . . . . . . . . . . . . . . . . . 54 8.3.2. Delegations . . . . . . . . . . . . . . . . . . . . . 53
8.3.3. Permission Checking . . . . . . . . . . . . . . . . . 54 8.3.3. Permission Checking . . . . . . . . . . . . . . . . . 53
8.3.4. Object Creation . . . . . . . . . . . . . . . . . . . 55 8.3.4. Object Creation . . . . . . . . . . . . . . . . . . . 54
8.3.5. Existing Objects . . . . . . . . . . . . . . . . . . . 55 8.3.5. Existing Objects . . . . . . . . . . . . . . . . . . . 54
8.3.6. Label Changes . . . . . . . . . . . . . . . . . . . . 55 8.3.6. Label Changes . . . . . . . . . . . . . . . . . . . . 54
8.4. Procedure 16: CB_ATTR_CHANGED - Notify Client that the 8.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 55
File's Attributes Changed . . . . . . . . . . . . . . . . 56 8.5. Discovery of Server LNFS Support . . . . . . . . . . . . . 55
8.5. pNFS Considerations . . . . . . . . . . . . . . . . . . . 57 8.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 56
8.6. Discovery of Server LNFS Support . . . . . . . . . . . . . 57 8.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 56
8.7. MAC Security NFS Modes of Operation . . . . . . . . . . . 58 8.6.2. Smart Client Mode . . . . . . . . . . . . . . . . . . 57
8.7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 58 8.6.3. Smart Server Mode . . . . . . . . . . . . . . . . . . 58
8.7.2. Smart Client Mode . . . . . . . . . . . . . . . . . . 59 8.7. Security Considerations . . . . . . . . . . . . . . . . . 59
8.7.3. Smart Server Mode . . . . . . . . . . . . . . . . . . 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
8.8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 61 10. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . . 59
8.8.1. Full MAC labeling support for remotely mounted 11. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . . 63
filesystems . . . . . . . . . . . . . . . . . . . . . 61 11.1. Operation 59: COPY - Initiate a server-side copy . . . . . 63
8.8.2. MAC labeling of virtual machine images stored on 11.2. Operation 60: COPY_ABORT - Cancel a server-side copy . . . 71
the network . . . . . . . . . . . . . . . . . . . . . 61
8.8.3. International Traffic in Arms Regulations (ITAR) . . . 62
8.8.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . 62
8.8.5. Simple security label storage . . . . . . . . . . . . 63
8.8.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . 63
8.8.7. Multi-Level Security . . . . . . . . . . . . . . . . . 64
8.9. Security Considerations . . . . . . . . . . . . . . . . . 65
9. Security Considerations . . . . . . . . . . . . . . . . . . . 66
10. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . . 66
11. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . . 69
11.1. Operation 59: COPY - Initiate a server-side copy . . . . . 69
11.2. Operation 60: COPY_ABORT - Cancel a server-side copy . . . 77
11.3. Operation 61: COPY_NOTIFY - Notify a source server of 11.3. Operation 61: COPY_NOTIFY - Notify a source server of
a future copy . . . . . . . . . . . . . . . . . . . . . . 78 a future copy . . . . . . . . . . . . . . . . . . . . . . 72
11.4. Operation 62: COPY_REVOKE - Revoke a destination 11.4. Operation 62: COPY_REVOKE - Revoke a destination
server's copy privileges . . . . . . . . . . . . . . . . . 80 server's copy privileges . . . . . . . . . . . . . . . . . 75
11.5. Operation 63: COPY_STATUS - Poll for status of a 11.5. Operation 63: COPY_STATUS - Poll for status of a
server-side copy . . . . . . . . . . . . . . . . . . . . . 81 server-side copy . . . . . . . . . . . . . . . . . . . . . 76
11.6. Operation 64: INITIALIZE . . . . . . . . . . . . . . . . . 83
11.6. Operation 64: INITIALIZE . . . . . . . . . . . . . . . . . 77
11.7. Modification to Operation 42: EXCHANGE_ID - 11.7. Modification to Operation 42: EXCHANGE_ID -
Instantiate Client ID . . . . . . . . . . . . . . . . . . 85 Instantiate Client ID . . . . . . . . . . . . . . . . . . 79
11.8. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 86 11.8. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 81
12. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 88 12. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 83
12.1. Operation 15: CB_COPY - Report results of a 12.1. Procedure 16: CB_ATTR_CHANGED - Notify Client that the
server-side copy . . . . . . . . . . . . . . . . . . . . . 88 File's Attributes Changed . . . . . . . . . . . . . . . . 83
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 89 12.2. Operation 15: CB_COPY - Report results of a
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89 server-side copy . . . . . . . . . . . . . . . . . . . . . 83
14.1. Normative References . . . . . . . . . . . . . . . . . . . 89 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
14.2. Informative References . . . . . . . . . . . . . . . . . . 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 91 14.1. Normative References . . . . . . . . . . . . . . . . . . . 85
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 92 14.2. Informative References . . . . . . . . . . . . . . . . . . 86
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 92 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 87
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 88
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 88
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 [10] and the second minor version, version, NFSv4.0, is described in [10] and the second minor version,
NFSv4.1, is described in [2]. It follows the guidelines for minor NFSv4.1, is described in [2]. It follows the guidelines for minor
versioning that are listed in Section 11 of RFC 3530bis. versioning that are listed in Section 11 of [10].
As a minor version, NFSv4.2 is consistent with the overall goals for As a minor version, NFSv4.2 is consistent with the overall goals for
NFSv4, but extends the protocol so as to better meet those goals, NFSv4, but extends the protocol so as to better meet those goals,
based on experiences with NFSv4.1. In addition, NFSv4.2 has adopted based on experiences with NFSv4.1. In addition, NFSv4.2 has adopted
some additional goals, which motivate some of the major extensions in some additional goals, which motivate some of the major extensions in
NFSv4.2. NFSv4.2.
1.2. Scope of This Document 1.2. Scope of This Document
This document describes the NFSv4.2 protocol. With respect to This document describes the NFSv4.2 protocol. With respect to
NFSv4.0 and NFSv4.1, this document does not: NFSv4.0 and NFSv4.1, this document does not:
o describe the NFSv4.0 or NFSv4.1 protocols, except where needed to o describe the NFSv4.0 or NFSv4.1 protocols, except where needed to
contrast with NFSv4.2. contrast with NFSv4.2.
o modify the specification of the NFSv4.0 or NFSv4.1 protocols. o modify the specification of the NFSv4.0 or NFSv4.1 protocols.
o clarify the NFSv4.0 or NFSv4.1 protocols. o clarify the NFSv4.0 or NFSv4.1 protocols. I.e., any
clarifications made here apply to NFSv4.2 and neither of the prior
protocols.
The full XDR for NFSv4.2 is presented in [3]. The full XDR for NFSv4.2 is presented in [3].
1.3. NFSv4.2 Goals 1.3. NFSv4.2 Goals
[[Comment.1: This needs fleshing out! --TH]]
1.4. Overview of NFSv4.2 Features 1.4. Overview of NFSv4.2 Features
[[Comment.2: This needs fleshing out! --TH]]
1.5. Differences from NFSv4.1 1.5. Differences from NFSv4.1
2. pNFS LAYOUTRETURN Error Handling [[Comment.3: This needs fleshing out! --TH]]
2. pNFS LAYOUTRETURN Error Handling
2.1. Introduction 2.1. Introduction
In the pNFS description provided in [2], the client is not enabled to In the pNFS description provided in [2], the client is not enabled to
relay an error code from the DS to the MDS. In the specification of relay an error code from the DS to the MDS. In the specification of
the Objects-Based Layout protocol [4], use is made of the opaque the Objects-Based Layout protocol [4], use is made of the opaque
lrf_body field of the LAYOUTRETURN argument to do such a relaying of lrf_body field of the LAYOUTRETURN argument to do such a relaying of
error codes. In this section, we define a new data structure to error codes. In this section, we define a new data structure to
enable the passing of error codes back to the MDS and provide some enable the passing of error codes back to the MDS and provide some
guidelines on what both the client and MDS should expect in such guidelines on what both the client and MDS should expect in such
circumstances. circumstances.
skipping to change at page 9, line 42 skipping to change at page 10, line 7
device error information. An MDS is also not required to device error information. An MDS is also not required to
automatically reinstate use of a previously problematic storage automatically reinstate use of a previously problematic storage
device; administrative intervention may be required instead. device; administrative intervention may be required instead.
A client MAY perform I/O via the MDS even when the client holds a A client MAY perform I/O via the MDS even when the client holds a
layout that covers the I/O; servers MUST support this client layout that covers the I/O; servers MUST support this client
behavior, and MAY recall layouts as needed to complete I/Os. behavior, and MAY recall layouts as needed to complete I/Os.
3. Sharing change attribute implementation details with NFSv4 clients 3. Sharing change attribute implementation details with NFSv4 clients
3.1. Abstract 3.1. Introduction
This document describes an extension to the NFSv4 protocol that
allows the server to share information about the implementation of
its change attribute with the client. The aim is to improve the
client's ability to determine the order in which parallel updates to
the same file were processed.
3.2. Introduction
Although both the NFSv4 [10] and NFSv4.1 protocol [2], define the Although both the NFSv4 [10] and NFSv4.1 protocol [2], define the
change attribute as being mandatory to implement, there is little in change attribute as being mandatory to implement, there is little in
the way of guidance. The only feature that is mandated by the spec the way of guidance. The only feature that is mandated by them is
is that the value must change whenever the file data or metadata that the value must change whenever the file data or metadata change.
change.
While this allows for a wide range of implementations, it also leaves While this allows for a wide range of implementations, it also leaves
the client with a conundrum: how does it determine which is the most the client with a conundrum: how does it determine which is the most
recent value for the change attribute in a case where several RPC recent value for the change attribute in a case where several RPC
calls have been issued in parallel? In other words if two COMPOUNDs, calls have been issued in parallel? In other words if two COMPOUNDs,
both containing WRITE and GETATTR requests for the same file, have both containing WRITE and GETATTR requests for the same file, have
been issued in parallel, how does the client determine which of the been issued in parallel, how does the client determine which of the
two change attribute values returned in the replies to the GETATTR two change attribute values returned in the replies to the GETATTR
requests corresponds to the most recent state of the file? In some requests corresponds to the most recent state of the file? In some
cases, the only recourse may be to send another COMPOUND containing a cases, the only recourse may be to send another COMPOUND containing a
third GETATTR that is fully serialised with the first two. third GETATTR that is fully serialised with the first two.
In order to avoid this kind of inefficiency, we propose a method to NFSv4.2 avoids this kind of inefficiency by allowing the server to
allow the server to share details about how the change attribute is share details about how the change attribute is expected to evolve,
expected to evolve, so that the client may immediately determine so that the client may immediately determine which, out of the
which, out of the several change attribute values returned by the several change attribute values returned by the server, is the most
server, is the most recent. recent.
3.3. Definition of the 'change_attr_type' per-file system attribute 3.2. Definition of the 'change_attr_type' per-file system attribute
enum change_attr_typeinfo { enum change_attr_typeinfo {
NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR = 0, NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR = 0,
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER = 1, NFS4_CHANGE_TYPE_IS_VERSION_COUNTER = 1,
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS = 2, NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS = 2,
NFS4_CHANGE_TYPE_IS_TIME_METADATA = 3, NFS4_CHANGE_TYPE_IS_TIME_METADATA = 3,
NFS4_CHANGE_TYPE_IS_UNDEFINED = 4 NFS4_CHANGE_TYPE_IS_UNDEFINED = 4
}; };
+------------------+----+---------------------------+-----+ +------------------+----+---------------------------+-----+
| Name | Id | Data Type | Acc | | Name | Id | Data Type | Acc |
+------------------+----+---------------------------+-----+ +------------------+----+---------------------------+-----+
| change_attr_type | XX | enum change_attr_typeinfo | R | | change_attr_type | XX | enum change_attr_typeinfo | R |
+------------------+----+---------------------------+-----+ +------------------+----+---------------------------+-----+
The proposed solution is to enable the NFS server to provide The solution enables the NFS server to provide additional information
additional information about how it expects the change attribute about how it expects the change attribute value to evolve after the
value to evolve after the file data or metadata has changed. To do file data or metadata has changed. 'change_attr_type' is defined as a
so, we define a new recommended attribute, 'change_attr_type', which new recommended attribute, and takes values from enum
may take values from enum change_attr_typeinfo as follows: change_attr_typeinfo as follows:
NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR: The change attribute value MUST NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR: The change attribute value MUST
monotonically increase for every atomic change to the file monotonically increase for every atomic change to the file
attributes, data or directory contents. attributes, data or directory contents.
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER: The change attribute value MUST NFS4_CHANGE_TYPE_IS_VERSION_COUNTER: The change attribute value MUST
be incremented by one unit for every atomic change to the file be incremented by one unit for every atomic change to the file
attributes, data or directory contents. This property is attributes, data or directory contents. This property is
preserved when writing to pNFS data servers. preserved when writing to pNFS data servers.
skipping to change at page 12, line 6 skipping to change at page 12, line 6
Finally, if the client sees NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, it Finally, if the client sees NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, it
has the ability to predict what the resulting change attribute value has the ability to predict what the resulting change attribute value
should be after a COMPOUND containing a SETATTR, WRITE, or CREATE. should be after a COMPOUND containing a SETATTR, WRITE, or CREATE.
This again allows it to detect changes made in parallel by another This again allows it to detect changes made in parallel by another
client. The value NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS permits client. The value NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS permits
the same, but only if the client is not doing pNFS WRITEs. the same, but only if the client is not doing pNFS WRITEs.
4. NFS Server-side Copy 4. NFS Server-side Copy
4.1. Introduction 4.1. Introduction
This document describes a server-side copy feature for the NFS This section describes a server-side copy feature for the NFS
protocol. protocol.
The server-side copy feature provides a mechanism for the NFS client The server-side copy feature provides a mechanism for the NFS client
to perform a file copy on the server without the data being to perform a file copy on the server without the data being
transmitted back and forth over the network. transmitted back and forth over the network.
Without this feature, an NFS client copies data from one location to Without this feature, an NFS client copies data from one location to
another by reading the data from the server over the network, and another by reading the data from the server over the network, and
then writing the data back over the network to the server. Using then writing the data back over the network to the server. Using
this server-side copy operation, the client is able to instruct the this server-side copy operation, the client is able to instruct the
skipping to change at page 32, line 19 skipping to change at page 32, line 19
impose on the MDS to asynchronously read the data from the DS. impose on the MDS to asynchronously read the data from the DS.
Furthermore, each DS MUST not report to a client either a sparse ADB Furthermore, each DS MUST not report to a client either a sparse ADB
or data which belongs to another DS. One implication of this or data which belongs to another DS. One implication of this
requirement is that the app_data_block4's adb_block_size MUST be requirement is that the app_data_block4's adb_block_size MUST be
either be the stripe width or the stripe width must be an even either be the stripe width or the stripe width must be an even
multiple of it. multiple of it.
The second implication here is that the DS must be able to use the The second implication here is that the DS must be able to use the
Control Protocol to determine from the MDS where the sparse ADBs Control Protocol to determine from the MDS where the sparse ADBs
occur. [[Comment.1: Need to discuss what happens if after the file occur. [[Comment.4: Need to discuss what happens if after the file
is being written to and an INITIALIZE occurs? --TH]] Perhaps instead is being written to and an INITIALIZE occurs? --TH]] Perhaps instead
of the DS pulling from the MDS, the MDS pushes to the DS? Thus an of the DS pulling from the MDS, the MDS pushes to the DS? Thus an
INITIALIZE causes a new push? [[Comment.2: Still need to consider INITIALIZE causes a new push? [[Comment.5: Still need to consider
race cases of the DS getting a WRITE and the MDS getting an race cases of the DS getting a WRITE and the MDS getting an
INITIALIZE. --TH]] INITIALIZE. --TH]]
5.3. An Example of Detecting Corruption 5.3. An Example of Detecting Corruption
In this section, we define an ADB format in which corruption can be In this section, we define an ADB format in which corruption can be
detected. Note that this is just one possible format and means to detected. Note that this is just one possible format and means to
detect corruption. detect corruption.
Consider a very basic implementation of an operating system's disk Consider a very basic implementation of an operating system's disk
skipping to change at page 39, line 35 skipping to change at page 39, line 35
NFS4ERR_DIR The current filehandle is of type NF4DIR. NFS4ERR_DIR The current filehandle is of type NF4DIR.
NFS4ERR_SYMLINK The current filehandle is of type NF4LNK. NFS4ERR_SYMLINK The current filehandle is of type NF4LNK.
NFS4ERR_WRONG_TYPE The current filehandle does not designate an NFS4ERR_WRONG_TYPE The current filehandle does not designate an
ordinary file. ordinary file.
7. Sparse Files 7. Sparse Files
WARNING: Most of this section needs to be reworked because of the WARNING: Some of this section needs to be reworked because of the
work going on in the ADB section. work going on in the ADB section.
7.1. Introduction 7.1. Introduction
A sparse file is a common way of representing a large file without A sparse file is a common way of representing a large file without
having to utilize all of the disk space for it. Consequently, a having to utilize all of the disk space for it. Consequently, a
sparse file uses less physical space than its size indicates. This sparse file uses less physical space than its size indicates. This
means the file contains 'holes', byte ranges within the file that means the file contains 'holes', byte ranges within the file that
contain no data. Most modern file systems support sparse files, contain no data. Most modern file systems support sparse files,
including most UNIX file systems and NTFS, but notably not Apple's including most UNIX file systems and NTFS, but notably not Apple's
skipping to change at page 50, line 15 skipping to change at page 50, line 15
7.7.5. Dense and Sparse pNFS File Layouts 7.7.5. Dense and Sparse pNFS File Layouts
The hole information returned form a data server must be understood The hole information returned form a data server must be understood
by pNFS clients using both Dense or Sparse file layout types. Does by pNFS clients using both Dense or Sparse file layout types. Does
the current READ_PLUS return value work for both layout types? Does the current READ_PLUS return value work for both layout types? Does
the data server know if it is using dense or sparse so that it can the data server know if it is using dense or sparse so that it can
return the correct hole_offset and hole_length values? return the correct hole_offset and hole_length values?
8. Labeled NFS 8. Labeled NFS
WARNING: Need to pull out the requirements.
8.1. Introduction 8.1. Introduction
Mandatory Access Control (MAC) systems have been mainstreamed in
modern operating systems such as Linux (R), FreeBSD (R), Solaris
(TM), and Windows Vista (R). MAC systems bind security attributes to
subjects (processes) and objects within a system. These attributes
are used with other information in the system to make access control
decisions.
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 MAC models base their access and resource ownership. In contrast Mandatory Access Control (MAC)
control decisions on the label on the subject (usually a process) and models base their access control decisions on the label on the
the object it wishes to access. These labels may contain user subject (usually a process) and the object it wishes to access.
identity information but usually contain additional information. In These labels may contain user identity information but usually
DAC systems users are free to specify the access rules for resources contain additional information. In DAC systems users are free to
that they own. MAC models base their security decisions on a system specify the access rules for resources that they own. MAC models
wide policy established by an administrator or organization which the base their security decisions on a system wide policy established by
users do not have the ability to override. DAC systems offer no real an administrator or organization which the users do not have the
protection against malicious or flawed software due to each program ability to override. In this section, we add a MAC model to NFSv4.
running with the full permissions of the user executing it.
Inversely MAC models can confine malicious or flawed software and
usually act at a finer granularity than their DAC counterparts.
People desire to use NFSv4 with these systems. A mechanism is
required to provide security attribute information to NFSv4 clients
and servers. This mechanism has the following requirements:
(1) Clients must be able to convey to the server the security
attribute of the subject making the access request. The server
may provide a mechanism to enforce MAC policy based on the
requesting subject's security attribute.
(2) Server must be able to store and retrieve the security attribute
of exported files as requested by the client.
(3) Server must provide a mechanism for notifying clients of
attribute changes of files on the server.
(4) Clients and Servers must be able to negotiate Label Formats and
Domains of Interpretation (DOI) and provide a mechanism to
translate between them as needed.
These four requirements are key to the system with only requirements
(2) and (3) requiring changes to NFSv4. The ability to convey the
security attribute of the subject as described in requirement (1)
falls upon the RPC layer to implement (see [6]). Requirement (4)
allows communication between different MAC implementations. The
management of label formats, DOIs, and the translation between them
does not require any support from NFSv4 on a protocol level and is
out of the scope of this document.
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
such as the ability to set the label value upon object creation. such as the ability to set the label value upon object creation.
Access control on these attributes are done through a combination of Access control on these attributes are done through a combination of
two mechanisms. As with other recommended attributes on file objects two mechanisms. As with other recommended attributes on file objects
the usual DAC checks (ACLs and permission bits) will be performed to the usual DAC checks (ACLs and permission bits) will be performed to
ensure that proper file ownership is enforced. In addition a MAC ensure that proper file ownership is enforced. In addition a MAC
system MAY be employed on the client, server, or both to enforce system MAY be employed on the client, server, or both to enforce
skipping to change at page 53, line 14 skipping to change at page 52, line 19
o Must provide the ability to atomically set security information o Must provide the ability to atomically set security information
upon object creation upon object creation
o Must provide the ability to enforce access control decisions both o Must provide the ability to enforce access control decisions both
on the client and the server on the client and the server
o Must not expose an object to either the client or server name o Must not expose an object to either the client or server name
space before its security information has been bound to it. space before its security information has been bound to it.
NFSv4 provides several options for implementing the security NFSv4 implements the security attribute as a recommended attribute.
attribute. The first option is to implement the security attribute These attributes have a fixed format and semantics, which conflicts
as a named attribute. Named attributes provide flexibility since with the flexible nature of the security attribute. To resolve this
they are treated as an opaque field but lack a way to atomically set the security attribute consists of two components. The first
the attribute on creation. In addition, named attributes themselves component is a LFS as defined in [22] to allow for interoperability
are file system objects which need to be assigned a security between MAC mechanisms. The second component is an opaque field
attribute. This raises the question of how to assign security which is the actual security attribute data. To allow for various
attributes to the file and directories used to hold the security MAC models NFSv4 should be used solely as a transport mechanism for
attribute for the file in question. The inability to atomically the security attribute. It is the responsibility of the endpoints to
assign the security attribute on file creation and the necessity to consume the security attribute and make access decisions based on
assign security attributes to its sub-components makes named their respective models. In addition, creation of objects through
attributes unacceptable as a method for storing security attributes. OPEN and CREATE allows for the security attribute to be specified
upon creation. By providing an atomic create and set operation for
The second option is to implement the security attribute as a the security attribute it is possible to enforce the second and
recommended attribute. These attributes have a fixed format and fourth requirements. The recommended attribute FATTR4_SEC_LABEL will
semantics, which conflicts with the flexible nature of the security be used to satisfy this requirement.
attribute. To resolve this the security attribute consists of two
components. The first component is a LFS as defined in [22] to allow
for interoperability between MAC mechanisms. The second component is
an opaque field which is the actual security attribute data. To
allow for various MAC models NFSv4 should be used solely as a
transport mechanism for the security attribute. It is the
responsibility of the endpoints to consume the security attribute and
make access decisions based on their respective models. In addition,
creation of objects through OPEN and CREATE allows for the security
attribute to be specified upon creation. By providing an atomic
create and set operation for the security attribute it is possible to
enforce the second and fourth requirements. The recommended
attribute FATTR4_SEC_LABEL will be used to satisfy this requirement.
8.3.1. Interpreting FATTR4_SEC_LABEL 8.3.1. Interpreting FATTR4_SEC_LABEL
The XDR [11] necessary to implement Labeled NFSv4 is presented in The XDR [11] necessary to implement Labeled NFSv4 is presented below:
Figure 6:
const FATTR4_SEC_LABEL = 81;
typedef uint32_t policy4; const FATTR4_SEC_LABEL = 81;
struct labelformat_spec4 {
policy4 lfs_lfs;
policy4 lfs_pi;
};
struct sec_label_attr_info { typedef uint32_t policy4;
labelformat_spec4 slai_lfs;
opaque slai_data<>;
};
Figure 6 Figure 6
struct labelformat_spec4 {
policy4 lfs_lfs;
policy4 lfs_pi;
};
struct sec_label_attr_info {
labelformat_spec4 slai_lfs;
opaque slai_data<>;
};
The FATTR4_SEC_LABEL contains an array of two components with the The FATTR4_SEC_LABEL contains an array of two components with the
first component being an LFS. It serves to provide the receiving end first component being an LFS. It serves to provide the receiving end
with the information necessary to translate the security attribute with the information necessary to translate the security attribute
into a form that is usable by the endpoint. Label Formats assigned into a form that is usable by the endpoint. Label Formats assigned
an LFS may optionally choose to include a Policy Identifier field to an LFS may optionally choose to include a Policy Identifier field to
allow for complex policy deployments. The LFS and Label Format allow for complex policy deployments. The LFS and Label Format
Registry are described in detail in [22]. The translation used to Registry are described in detail in [22]. The translation used to
interpret the security attribute is not specified as part of the interpret the security attribute is not specified as part of the
protocol as it may depend on various factors. The second component protocol as it may depend on various factors. The second component
is an opaque section which contains the data of the attribute. This is an opaque section which contains the data of the attribute. This
skipping to change at page 55, line 5 skipping to change at page 53, line 49
all changes back to the server and relinquish the delegation. all changes back to the server and relinquish the delegation.
8.3.3. Permission Checking 8.3.3. Permission Checking
It is not feasible to enumerate all possible MAC models and even It is not feasible to enumerate all possible MAC models and even
levels of protection within a subset of these models. This means levels of protection within a subset of these models. This means
that the NFSv4 client and servers cannot be expected to directly make that the NFSv4 client and servers cannot be expected to directly make
access control decisions based on the security attribute. Instead access control decisions based on the security attribute. Instead
NFSv4 should defer permission checking on this attribute to the host NFSv4 should defer permission checking on this attribute to the host
system. These checks are performed in addition to existing DAC and system. These checks are performed in addition to existing DAC and
ACL checks outlined in the NFSv4 protocol. Section 8.7 gives a ACL checks outlined in the NFSv4 protocol. Section 8.6 gives a
specific example of how the security attribute is handled under a specific example of how the security attribute is handled under a
particular MAC model. particular MAC model.
8.3.4. Object Creation 8.3.4. Object Creation
When creating files in NFSv4 the OPEN and CREATE operations are used. When creating files in NFSv4 the OPEN and CREATE operations are used.
One of the parameters to these operations is an fattr4 structure One of the parameters to these operations is an fattr4 structure
containing the attributes the file is to be created with. This containing the attributes the file is to be created with. This
allows NFSv4 to atomically set the security attribute of files upon allows NFSv4 to atomically set the security attribute of files upon
creation. When a client is MAC aware it must always provide the creation. When a client is MAC aware it must always provide the
initial security attribute upon file creation. In the event that the initial security attribute upon file creation. In the event that the
server is the only MAC aware entity in the system it should ignore server is the only MAC aware entity in the system it should ignore
the security attribute specified by the client and instead make the the security attribute specified by the client and instead make the
determination itself. A more in depth explanation can be found in determination itself. A more in depth explanation can be found in
Section 8.7. Section 8.6.
8.3.5. Existing Objects 8.3.5. Existing Objects
Note that under the MAC model, all objects must have labels. Note that under the MAC model, all objects must have labels.
Therefore, if an existing server is upgraded to include LNFS support, Therefore, if an existing server is upgraded to include LNFS support,
then it is the responsibility of the security system to define the then it is the responsibility of the security system to define the
behavior for existing objects. For example, if the security system behavior for existing objects. For example, if the security system
is LFS 0, which means the server just stores and returns labels, then is LFS 0, which means the server just stores and returns labels, then
existing files should return labels which are set to an empty value. existing files should return labels which are set to an empty value.
skipping to change at page 56, line 7 skipping to change at page 54, line 51
As the server is always presented with the subject label from the As the server is always presented with the subject label from the
client, it does not necessarily need to communicate the fact that 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 label has changed to the client. In the cases where the change
outright denies the client access, the client will be able to quickly outright denies the client access, the client will be able to quickly
determine that there is a new label in effect. It is in cases where determine that there is a new label in effect. It is in cases where
the client may share the same object between multiple subjects or a the client may share the same object between multiple subjects or a
security system which is not strictly hierarchical that the security system which is not strictly hierarchical that the
CB_ATTR_CHANGED callback is very useful. It allows the server to CB_ATTR_CHANGED callback is very useful. It allows the server to
inform the clients that the cached security attribute is now stale. inform the clients that the cached security attribute is now stale.
In the scenario presented in Section 8.8.5, the clients are smart and Consider a system in which the clients enforce MAC checks and and the
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 smart client. So The way in which MAC labels are enforced is by the smart client. So
if client A changes a security label on a file, then the server MUST if client A changes a security label on a file, then the server MUST
inform all clients that have the file opened that the label has inform all clients that have the file opened that the label has
changed via CB_ATTR_CHANGED. Then the clients MUST retrieve the new changed via CB_ATTR_CHANGED. Then the clients MUST retrieve the new
label and MUST enforce access via the new attribute values. label and MUST enforce access via the new attribute values.
[[Comment.3: Describe a LFS of 0, which will be the means to indicate [[Comment.6: Describe a LFS of 0, which will be the means to indicate
such a deployment. In the current LFR, 0 is marked as reserved. If such a deployment. In the current LFR, 0 is marked as reserved. If
we use it, then we define the default LFS to be used by a LNFS aware we use it, then we define the default LFS to be used by a LNFS aware
server. I.e., it lets smart clients work together in the face of a server. I.e., it lets smart clients work together in the face of a
dumb server. Note that will supporting this system is optional, it dumb server. Note that will supporting this system is optional, it
will make for a very good debugging mode during development. I.e., will make for a very good debugging mode during development. I.e.,
even if a server does not deploy with another security system, this even if a server does not deploy with another security system, this
mode gets your foot in the door. --TH]] mode gets your foot in the door. --TH]]
8.4. Procedure 16: CB_ATTR_CHANGED - Notify Client that the File's 8.4. pNFS Considerations
Attributes Changed
8.4.1. ARGUMENTS
struct CB_ATTR_CHANGED4args {
nfs_fh4 acca_fh;
bitmap4 acca_critical;
bitmap4 acca_info;
};
8.4.2. RESULTS
struct CB_ATTR_CHANGED4res {
nfsstat4 accr_status;
};
8.4.3. DESCRIPTION
The CB_ATTR_CHANGED callback operation is used by the server to
indicate to the client that the file's attributes have been modified
on the server. The server does not convey how the attributes have
changed, just that they have been modified. The server can inform
the client about both critical and informational attribute changes in
the bitmask arguments. The client SHOULD query the server about all
attributes set in acca_critical. For all changes reflected in
acca_info, the client can decide whether or not it wants to poll the
server.
The CB_ATTR_CHANGED callback operation with the FATTR4_SEC_LABEL set
in acca_critical is the method used by the server to indicate that
the MAC label for the file referenced by acca_fh has changed. In
many ways, the server does not care about the result returned by the
client.
8.5. pNFS Considerations
This section examines the issues in deploying LNFS in a pNFS This section examines the issues in deploying LNFS in a pNFS
community of servers. community of servers.
8.5.1. MAC Label Checks 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 [2] already has provisions for Fortunately, the NFSv4.1 protocol [2] already has provisions for
doing access level checks from the DS to the MDS. In order for the 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 SHOULD DS to validate the subject label presented by the client, it SHOULD
utilize this mechanism. utilize this mechanism.
If a file's FATTR4_SEC_LABEL is changed, then the MDS should utilize If a file's FATTR4_SEC_LABEL is changed, then the MDS should utilize
CB_ATTR_CHANGED to inform the client of that fact. If the MDS is CB_ATTR_CHANGED to inform the client of that fact. If the MDS is
maintaining maintaining
8.6. Discovery of Server LNFS Support 8.5. Discovery of Server LNFS Support
The server can easily determine that a client supports LNFS when it The server can easily determine that a client supports LNFS when it
queries for the FATTR4_SEC_LABEL label for an object. Note that it queries for the FATTR4_SEC_LABEL label for an object. Note that it
cannot assume that the presence of RPCSEC_GSSv3 indicates LNFS cannot assume that the presence of RPCSEC_GSSv3 indicates LNFS
support. The client might need to discover which LFS the server support. The client might need to discover which LFS the server
supports. supports.
A server which supports LNFS MUST allow a client with any subject A server which supports LNFS MUST allow a client with any subject
label to retrieve the FATTR4_SEC_LABEL attribute for the root label to retrieve the FATTR4_SEC_LABEL attribute for the root
filehandle, ROOTFH. The following compound must always succeed as filehandle, ROOTFH. The following compound must always succeed as
skipping to change at page 58, line 7 skipping to change at page 56, line 15
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.
8.7. MAC Security NFS Modes of Operation 8.6. MAC Security NFS Modes of Operation
A system using Labeled NFS may operate in three modes. The first A system using Labeled NFS may operate in three modes. The first
mode provides the most protection and is called "full mode". In this mode provides the most protection and is called "full mode". In this
mode both the client and server implement a MAC model allowing each mode both the client and server implement a MAC model allowing each
end to make an access control decision. The remaining two modes are end to make an access control decision. The remaining two modes are
variations on each other and are called "smart client" and "smart variations on each other and are called "smart client" and "smart
server" modes. In these modes one end of the connection is not server" modes. In these modes one end of the connection is not
implementing a MAC model and because of this these operating modes implementing a MAC model and because of this these operating modes
offer less protection than full mode. offer less protection than full mode.
8.7.1. Full Mode 8.6.1. Full Mode
Full mode environments consist of MAC aware NFSv4 servers and clients Full mode environments consist of MAC aware NFSv4 servers and clients
and may be composed of mixed MAC models and policies. The system and may be composed of mixed MAC models and policies. The system
requires that both the client and server have an opportunity to requires that both the client and server have an opportunity to
perform an access control check based on all relevant information 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. The security attribute
of the subject making the request is transported at the RPC layer of the subject making the request is transported at the RPC layer
using the mechanism described in RPCSECGSSv3 [6]. using the mechanism described in RPCSECGSSv3 [6].
8.7.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.
Security attributes on the client and server may vary based on MAC Security attributes on the client and server may vary based on MAC
skipping to change at page 59, line 5 skipping to change at page 57, line 11
identify the format and meaning of the opaque portion of the security identify the format and meaning of the opaque portion of the security
attribute. A full mode environment may contain hosts operating in attribute. A full mode environment may contain hosts operating in
several different LFSs and DOIs. In this case a mechanism for several different LFSs and DOIs. In this case a mechanism for
translating the opaque portion of the security attribute is needed. translating the opaque portion of the security attribute is needed.
The actual translation function will vary based on MAC model and The actual translation function will vary based on MAC model and
policy and is out of the scope of this document. If a translation is policy and is out of the scope of this document. If a translation is
unavailable for a given LFS and DOI then the request SHOULD be unavailable for a given LFS and DOI then the request SHOULD be
denied. Another recourse is to allow the host to provide a fallback denied. Another recourse is to allow the host to provide a fallback
mapping for unknown security attributes. mapping for unknown security attributes.
8.7.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 extracts the
security attribute conveyed in the RPC request. The server then uses security attribute conveyed in the RPC request. The server then uses
this security attribute and the attribute of the object the client is this security attribute and the attribute of the object the client is
trying to access to make an access control decision. If the server's trying to access to make an access control decision. If the server's
policy allows this access it will fulfill the client's request, policy allows this access it will fulfill the client's request,
otherwise it will return NFS4ERR_ACCESS. otherwise it will return NFS4ERR_ACCESS.
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. An example of this can be seen in Section 8.8.7.1. peer.
8.7.2. Smart Client Mode 8.6.2. Smart Client Mode
Smart client environments consist of NFSv4 servers that are not MAC Smart client environments consist of NFSv4 servers that are not MAC
aware but NFSv4 clients that are. Clients in this environment are aware but NFSv4 clients that are. Clients in this environment are
may consist of groups implementing different MAC models policies. may consist of groups implementing different MAC models policies.
The system requires that all clients in the environment be The system requires that all clients in the environment be
responsible for access control checks. Due to the amount of trust responsible for access control checks. Due to the amount of trust
placed in the clients this mode is only to be used in a trusted placed in the clients this mode is only to be used in a trusted
environment. environment.
8.7.2.1. Initial Labeling and Translation 8.6.2.1. Initial Labeling and Translation
Just like in full mode the client is responsible for determining the Just like in full mode the client is responsible for determining the
initial label upon object creation. The server in smart client mode initial label upon object creation. The server in smart client mode
does not implement a MAC model, however, it may provide the ability does not implement a MAC model, however, it may provide the ability
to restrict the creation and labeling of object with certain labels to restrict the creation and labeling of object with certain labels
based on different criteria as described in Section 8.7.1.2. based on different criteria as described in Section 8.6.1.2.
In a smart client environment a group of clients operate in a single In a smart client environment a group of clients operate in a single
DOI. This removes the need for the clients to maintain a set of DOI DOI. This removes the need for the clients to maintain a set of DOI
translations. Servers should provide a method to allow different translations. Servers should provide a method to allow different
groups of clients to access the server at the same time. However it groups of clients to access the server at the same time. However it
should not let two groups of clients operating in different DOIs to should not let two groups of clients operating in different DOIs to
access the same files. access the same files.
8.7.2.2. Policy Enforcement 8.6.2.2. Policy Enforcement
In smart client mode access control decisions are made by the In smart client mode access control decisions are made by the
clients. When a client accesses an object it obtains the security clients. When a client accesses an object it obtains the security
attribute of the object from the server and combines it with the attribute of the object from the server and combines it with the
security attribute of the process making the request to make an security attribute of the process making the request to make an
access control decision. This check is in addition to the DAC checks access control decision. This check is in addition to the DAC checks
provided by NFSv4 so this may fail based on the DAC criteria even if provided by NFSv4 so this may fail based on the DAC criteria even if
the MAC policy grants access. As the policy check is located on the the MAC policy grants access. As the policy check is located on the
client an access control denial should take the form that is native client an access control denial should take the form that is native
to the platform. to the platform.
8.7.3. Smart Server Mode 8.6.3. Smart Server Mode
Smart server environments consist of NFSv4 servers that are MAC aware Smart server environments consist of NFSv4 servers that are MAC aware
and one or more MAC unaware clients. The server is the only entity and one or more MAC unaware clients. The server is the only entity
enforcing policy, and may selectively provide standard NFS services enforcing policy, and may selectively provide standard NFS services
to clients based on their authentication credentials and/or 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
configuration-specific. configuration-specific.
8.7.3.1. Initial Labeling and Translation 8.6.3.1. Initial Labeling and Translation
In smart server mode all labeling and access control decisions are In smart server mode all labeling and access control decisions are
performed by the NFSv4 server. In this environment the NFSv4 clients performed by the NFSv4 server. In this environment the NFSv4 clients
are not MAC aware so they cannot provide input into the access are not MAC aware so they cannot provide input into the access
control decision. This requires the server to determine the initial control decision. This requires the server to determine the initial
labeling of objects. Normally the subject to use in this calculation labeling of objects. Normally the subject to use in this calculation
would originate from the client. Instead the NFSv4 server may choose would originate from the client. Instead the NFSv4 server may choose
to assign the subject security attribute based on their to assign the subject security attribute based on their
authentication credentials and/or associated network attributes authentication credentials and/or associated network attributes
(e.g., IP address, network interface). (e.g., IP address, network interface).
In smart server mode security attributes are contained solely within In smart server mode security attributes are contained solely within
the NFSv4 server. This means that all security attributes used in the NFSv4 server. This means that all security attributes used in
the system remain within a single LFS and DOI. Since security the system remain within a single LFS and DOI. Since security
attributes will not cross DOIs or change format there is no need to attributes will not cross DOIs or change format there is no need to
provide any translation functionality above that which is needed provide any translation functionality above that which is needed
internally by the MAC model. internally by the MAC model.
8.7.3.2. Policy Enforcement 8.6.3.2. Policy Enforcement
All access control decisions in smart server mode are made by the All access control decisions in smart server mode are made by the
server. The server will assign the subject a security attribute server. The server will assign the subject a security attribute
based on some criteria (e.g., IP address, network interface). Using based on some criteria (e.g., IP address, network interface). Using
the newly calculated security attribute and the security attribute of the newly calculated security attribute and the security attribute of
the object being requested the MAC model makes the access control the object being requested the MAC model makes the access control
check and returns NFS4ERR_ACCESS on a denial and NFS4_OK on success. check and returns NFS4ERR_ACCESS on a denial and NFS4_OK on success.
This check is done transparently to the client so if the MAC This check is done transparently to the client so if the MAC
permission check fails the client may be unaware of the reason for permission check fails the client may be unaware of the reason for
the permission failure. When operating in this mode administrators the permission failure. When operating in this mode administrators
attempting to debug permission failures should be aware to check the attempting to debug permission failures should be aware to check the
MAC policy running on the server in addition to the DAC settings. MAC policy running on the server in addition to the DAC settings.
8.8. Use Cases 8.7. Security Considerations
MAC labeling is meant to allow NFSv4 to be deployed in site
configurable security schemes. The LFS and opaque data scheme allows
for flexibility to meet these different implementations. In this
section, we provide some examples of how NFSv4 could be deployed to
meet existing needs. This is not an exhaustive listing.
8.8.1. Full MAC labeling support for remotely mounted filesystems
In this case, we assume a local networked environment where the
servers and clients are under common administrative control. All
systems in this network have the same MAC implementation and
semantically identical MAC security labels for objects (i.e. labels
mean the same thing on different systems, even if the policies on
each system may differ to some extent). Clients will be able to
apply fine-grained MAC policy to objects accessed via NFS mounts, and
thus improve the overall consistency of MAC policy application within
this environment.
An example of this case would be where user home directories are
remotely mounted, and fine-grained MAC policy is implemented to
protect, for example, private user data from being read by malicious
web scripts running in the user's browser. With Labeled NFS, fine-
grained MAC labeling of the user's files will allow the local MAC
policy to be implemented and provide the desired protection.
8.8.2. MAC labeling of virtual machine images stored on the network
Virtualization is now a commonly implemented feature of modern
operating systems, and there is a need to ensure that MAC security
policy is able to to protect virtualized resources. A common
implementation scheme involves storing virtualized guest filesystems
on a networked server, which are then mounted remotely by guests upon
instantiation. In this case, there is a need to ensure that the
local guest kernel is able to access fine-grained MAC labels on the
remotely mounted filesystem so that its MAC security policy can be
applied.
8.8.3. International Traffic in Arms Regulations (ITAR)
The International Traffic in Arms Regulations (ITAR) is put forth by
the United States Department of State, Directorate of Defense and
Trade Controls. ITAR places strict requirements on the export and
thus access of defense articles and defense services. Organizations
that manage projects with articles and services deemed as within the
scope of ITAR must ensure the regulations are met. The regulations
require an assurance that ITAR information is accessed on a need-to-
know basis, thus requiring strict, centrally managed access controls
on items labeled as ITAR. Additionally, organizations must be able
to prove that the controls were adequately maintained and that
foreign nationals were not permitted access to these defense articles
or service. ITAR control applicability may be dynamic; information
may become subject to ITAR after creation (e.g., when the defense
implications of technology are recognized).
8.8.4. Legal Hold/eDiscovery
Increased cases of legal holds on electronic sources of information
(ESI) have resulted in organizations taking a pro-active approach to
reduce the scope and thus costs associated with these activities.
ESI Data Maps are increasing in use and require support in operating
systems to strictly manage access controls in the case of a legal
hold. The sizeable quantity of information involved in a legal
discovery request may preclude making a copy of the information to a
separate system that manages the legal hold on the copies; this
results in a need to enforce the legal hold on the original
information.
Organizations are taking steps to map out the sources of information
that are most likely to be placed under a legal hold, these efforts
result in ESI Data Maps. ESI Data Maps specify the Electronic Source
of Information and the requirements for sensitivity and criticality.
In the case of a legal hold, the ESI data map and labels can be used
to ensure the legal hold is properly enforced on the predetermined
set of information. An ESI data map narrows the scope of a legal
hold to the predetermined ESI. The information must then be
protected at a level of security of which the weight and
admissibility of that evidence may be proved in a court of law.
Current systems use application level controls and do not adequately
meet the requirements. Labels may be used in advance when an ESI
data map exercise is conducted with controls being applied at the
time of a hold or labels may be applied to data sets during an
eDiscovery exercise to ensure the data protections are adequate
during the legal hold period.
Note that this use case requires multi-attribute labels, as both
information sensitivity (e.g., to disclosure) and information
criticality (e.g., to continued business operations) need to be
captured.
8.8.5. Simple security label storage
In this case, a mixed and loosely administered network is assumed,
where nodes may be running a variety of operating systems with
different security mechanisms and security policies. It is desired
that network file servers be simply capable of storing and retrieving
MAC security labels for clients which use such labels. The Labeled
NFS protocol would be implemented here solely to enable transport of
MAC security labels across the network. It should be noted that in
such an environment, overall security cannot be as strongly enforced
as in case (a), and that this scheme is aimed at allowing MAC-capable
clients to function with local MAC security policy enabled rather
than perhaps disabling it entirely.
8.8.6. Diskless Linux
A number of popular operating system distributions depend on a
mandatory access control (MAC) model to implement a kernel-enforced
security policy. Typically, such models assign particular roles to
individual processes, which limit or permit performing certain
operations on a set of files, directories, sockets, or other objects.
While the enforcing of the policy is typically a matter for the
diskless NFS client itself, the filesystem objects in such models
will typically carry MAC labels that are used to define policy on
access. These policies may, for instance, describe privilege
transitions that cannot be replicated using standard NFS ACL based
models.
For instance on a SYSV compatible system, if the 'init' process
spawns a process that attempts to start the 'NetworkManager'
executable, there may be a policy that sets up a role transition if
the 'init' process and 'NetworkManager' file labels match a
particular rule. Without this role transition, the process may find
itself having insufficient privileges to perform its primary job of
configuring network interfaces.
In setups of this type, a lot of the policy targets (such as sockets
or privileged system calls) are entirely local to the client. The
use of RPCSEC_GSSv3 for enforcing compliance at the server level is
therefore of limited value. The ability to permanently label files
and have those labels read back by the client is, however, crucial to
the ability to enforce that policy.
8.8.7. Multi-Level Security
In a MLS system objects are generally assigned a sensitivity level
and a set of compartments. The sensitivity levels within the system
are given an order ranging from lowest to highest classification
level. Read access to an object is allowed when the sensitivity
level of the subject "dominates" the object it wants to access. This
means that the sensitivity level of the subject is higher than that
of the object it wishes to access and that its set of compartments is
a super-set of the compartments on the object.
The rest of the section will just use sensitivity levels. In general
the example is a client that wishes to list the contents of a
directory. The system defines the sensitivity levels as Unclassified
(U), Secret (S), and Top Secret (TS). The directory to be searched
is labeled Top Secret which means access to read the directory will
only be granted if the subject making the request is also labeled Top
Secret.
8.8.7.1. Full Mode
In the first part of this example a process on the client is running
at the Secret level. The process issues a readdir system call which
enters the kernel. Before translating the readdir system call into a
request to the NFSv4 server the host operating system will consult
the MAC module to see if the operation is allowed. Since the process
is operating at Secret and the directory to be accessed is labeled
Top Secret the MAC module will deny the request and an error code is
returned to user space.
Consider a second case where instead of running at Secret the process
is running at Top Secret. In this case the sensitivity of the
process is equal to or greater than that of the directory so the MAC
module will allow the request. Now the readdir is translated into
the necessary NFSv4 call to the server. For the RPC request the
client is using the proper credential to assert to the server that
the process is running at Top Secret.
When the server receives the request it extracts the security label
from the RPC session and retrieves the label on the directory. The
server then checks with its MAC module if a Top Secret process is
allowed to read the contents of the Top Secret directory. Since this
is allowed by the policy then the server will return the appropriate
information back to the client.
In this example the policy on the client and server were both the
same. In the event that they were running different policies a
translation of the labels might be needed. In this case it could be
possible for a check to pass on the client and fail on the server.
The server may consider additional information when making its policy
decisions. For example the server could determine that a certain
subnet is only cleared for data up to Secret classification. If that
constraint was in place for the example above the client would still
succeed, but the server would fail since the client is asserting a
label that it is not able to use (Top Secret on a Secret network).
8.8.7.2. Smart Client Mode
In smart client mode the example is identical to the first part of a
full mode operation. A process on the client labeled Secret wishes
to access a Top Secret directory. As in the full mode example this
is denied since Secret does not dominate Top Secret. If the process
were operating at Top Secret it would pass the local access control
check and the NFSv4 operation would proceed as in a normal NFSv4
environment.
8.8.7.3. Smart Server Mode
In a smart server mode the client behaves as if it were in a normal
NFSv4 environment. Since the process on the client does not provide
a security attribute the server must define a mechanism for labeling
all requests from a client. Assume that the server is using the same
criteria used in the full mode example. The server sees the request
as coming from a subnet that is a Secret network. The server
determines that all clients on that subnet will have their requests
labeled with Secret. Since the directory on the server is labeled
Top Secret and Secret does not dominate Top Secret the server would
fail the request with NFS4ERR_ACCESS.
8.9. Security Considerations
This entire document deals with security issues. This entire document deals with security issues.
Depending on the level of protection the MAC system offers there may Depending on the level of protection the MAC system offers there may
be a requirement to tightly bind the security attribute to the data. be a requirement to tightly bind the security attribute to the data.
When either the client is in Smart Client Mode or server is in Smart When only one of the client or server enforces labels, it is
Server Mode, it is important to realize that the other side is not important to realize that the other side is not enforcing MAC
enforcing MAC protections. Alternate methods might be in use to protections. Alternate methods might be in use to handle the lack of
handle the lack of MAC support and care should be taken to identify MAC support and care should be taken to identify and mitigate threats
and mitigate threats from possible tampering outside of these from possible tampering outside of these methods.
methods.
An example of this is that a smart server that modifies READDIR or An example of this is that a server that modifies READDIR or LOOKUP
LOOKUP results based on the client's subject label might want to results based on the client's subject label might want to always
always construct the same subject label for a client which does not construct the same subject label for a client which does not present
present one. This will prevent a non-LNFS client from mixing entries one. This will prevent a non-LNFS client from mixing entries in the
in the directory cache. directory cache.
9. Security Considerations 9. Security Considerations
10. Operations: REQUIRED, RECOMMENDED, or OPTIONAL 10. 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 MUST NOT implement. The designation of MUST OPTIONAL to implement or MUST NOT implement. The designation of MUST
NOT implement is reserved for those operations that were defined in NOT implement is reserved for those operations that were defined in
either NFSv4.0 or NFSV4.1 and MUST NOT be implemented in NFSv4.2. either NFSv4.0 or NFSV4.1 and MUST NOT be implemented in NFSv4.2.
skipping to change at page 70, line 16 skipping to change at page 64, line 16
union COPY4res switch (nfsstat4 cr_status) { union COPY4res switch (nfsstat4 cr_status) {
case NFS4_OK: case NFS4_OK:
stateid4 cr_callback_id<1>; stateid4 cr_callback_id<1>;
default: default:
length4 cr_bytes_copied; length4 cr_bytes_copied;
}; };
11.1.3. DESCRIPTION 11.1.3. DESCRIPTION
The COPY operation is used for both intra- and inter-server copies. The COPY operation is used for both intra-server and inter-server
In both cases, the COPY is always sent from the client to the copies. In both cases, the COPY is always sent from the client to
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 combination of CURRENT_FH and
ca_destination. 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
skipping to change at page 76, line 32 skipping to change at page 70, line 32
the destination file or directory is not present. The client can the destination file or directory is not present. The client can
determine the correct location and reissue the operation with the determine the correct location and reissue the operation with the
correct location. correct location.
NFS4ERR_NOTSUPP: The copy offload operation is not supported by the NFS4ERR_NOTSUPP: The copy offload operation is not supported by the
NFS server receiving this request. NFS server receiving this request.
NFS4ERR_PARTNER_NOTSUPP: The remote server does not support the NFS4ERR_PARTNER_NOTSUPP: The remote server does not support the
server-to-server copy offload protocol. server-to-server copy offload protocol.
NFS4ERR_OFFLOAD_DENIED: The copy offload operation is supported by
both the source and the destination, but the destination is not
allowing it for this file. If the client sees this error, it
should fall back to the normal copy semantics.
NFS4ERR_PARTNER_NO_AUTH: The remote server does not authorize a NFS4ERR_PARTNER_NO_AUTH: The remote server does not authorize a
server-to-server copy offload operation. This may be due to the server-to-server copy offload operation. This may be due to the
client's failure to send the COPY_NOTIFY operation to the remote client's failure to send the COPY_NOTIFY operation to the remote
server, the remote server receiving a server-to-server copy server, the remote server receiving a server-to-server copy
offload request after the copy lease time expired, or for some offload request after the copy lease time expired, or for some
other permission problem. other permission problem.
NFS4ERR_FBIG: The copy operation would have caused the file to grow NFS4ERR_FBIG: The copy operation would have caused the file to grow
beyond the server's limit. beyond the server's limit.
skipping to change at page 84, line 35 skipping to change at page 79, line 14
1. The structure described by the app_data_block4 be imposed on the 1. The structure described by the app_data_block4 be imposed on the
file. file.
2. The contents described by the app_data_block4 be sparse. 2. The contents described by the app_data_block4 be sparse.
If the server supports the INITIALIZE operation, it still might not If the server supports the INITIALIZE operation, it still might not
support sparse files. So if it receives the INITIALIZE operation, support sparse files. So if it receives the INITIALIZE operation,
then it MUST populate the contents of the file with the initialized then it MUST populate the contents of the file with the initialized
ADBs. In other words, if the server supports INITIALIZE, then it ADBs. In other words, if the server supports INITIALIZE, then it
supports the concept of ADBs. [[Comment.4: Do we want to support an supports the concept of ADBs. [[Comment.7: Do we want to support an
asynchronous INITIALIZE? Do we have to? --TH]] asynchronous INITIALIZE? Do we have to? --TH]]
If the data was already initialized, There are two interesting If the data was already initialized, There are two interesting
scenarios: scenarios:
1. The data blocks are allocated. 1. The data blocks are allocated.
2. Initializing in the middle of an existing ADB. 2. Initializing in the middle of an existing ADB.
If the data blocks were already allocated, then the INITIALIZE is a If the data blocks were already allocated, then the INITIALIZE is a
hole punch operation. If INITIALIZE supports sparse files, then the hole punch operation. If INITIALIZE supports sparse files, then the
data blocks are to be deallocated. If not, then the data blocks are data blocks are to be deallocated. If not, then the data blocks are
to be rewritten in the indicated ADB format. [[Comment.5: Need to to be rewritten in the indicated ADB format. [[Comment.8: Need to
document interaction between space reservation and hole punching? document interaction between space reservation and hole punching?
--TH]] --TH]]
Since the server has no knowledge of ADBs, it should not report Since the server has no knowledge of ADBs, it should not report
misaligned creation of ADBs. Even while it can detect them, it misaligned creation of ADBs. Even while it can detect them, it
cannot disallow them, as the application might be in the process of cannot disallow them, as the application might be in the process of
changing the size of the ADBs. Thus the server must be prepared to changing the size of the ADBs. Thus the server must be prepared to
handle an INITIALIZE into an existing ADB. handle an INITIALIZE into an existing ADB.
This document does not mandate the manner in which the server stores This document does not mandate the manner in which the server stores
ADBs sparsely for a file. It does assume that if ADBs are stored ADBs sparsely for a file. It does assume that if ADBs are stored
sparsely, then the server can detect when an INITIALIZE arrives that sparsely, then the server can detect when an INITIALIZE arrives that
will force a new ADB to start inside an existing ADB. For example, will force a new ADB to start inside an existing ADB. For example,
skipping to change at page 85, line 15 skipping to change at page 79, line 42
misaligned creation of ADBs. Even while it can detect them, it misaligned creation of ADBs. Even while it can detect them, it
cannot disallow them, as the application might be in the process of cannot disallow them, as the application might be in the process of
changing the size of the ADBs. Thus the server must be prepared to changing the size of the ADBs. Thus the server must be prepared to
handle an INITIALIZE into an existing ADB. handle an INITIALIZE into an existing ADB.
This document does not mandate the manner in which the server stores This document does not mandate the manner in which the server stores
ADBs sparsely for a file. It does assume that if ADBs are stored ADBs sparsely for a file. It does assume that if ADBs are stored
sparsely, then the server can detect when an INITIALIZE arrives that sparsely, then the server can detect when an INITIALIZE arrives that
will force a new ADB to start inside an existing ADB. For example, will force a new ADB to start inside an existing ADB. For example,
assume that ADBi has a adb_block_size of 4k and that an INITIALIZE assume that ADBi has a adb_block_size of 4k and that an INITIALIZE
starts 1k inside ADBi. The server should [[Comment.6: Need to flesh starts 1k inside ADBi. The server should [[Comment.9: Need to flesh
this out. --TH]] this out. --TH]]
11.7. Modification to Operation 42: EXCHANGE_ID - Instantiate Client ID 11.7. Modification to Operation 42: EXCHANGE_ID - Instantiate Client ID
11.7.1. ARGUMENT 11.7.1. ARGUMENT
/* new */ /* new */
const EXCHGID4_FLAG_SUPP_FENCE_OPS = 0x00000004; const EXCHGID4_FLAG_SUPP_FENCE_OPS = 0x00000004;
11.7.2. RESULT 11.7.2. RESULT
skipping to change at page 88, line 7 skipping to change at page 83, line 7
ADBs, but it need not retrieve an entire sequences of ADBs. ADBs, but it need not retrieve an entire sequences of ADBs.
The server MUST return a whole ADB because if it does not, it must The server MUST return a whole ADB because if it does not, it must
expand that partial ADB before it sends it to the client. E.g., if expand that partial ADB before it sends it to the client. E.g., if
an ADB had a block size of 64k and the READ_PLUS was for 128k an ADB had a block size of 64k and the READ_PLUS was for 128k
starting at an offset of 32k inside the ADB, then the first 32k would starting at an offset of 32k inside the ADB, then the first 32k would
be converted to data. be converted to data.
12. NFSv4.2 Callback Operations 12. NFSv4.2 Callback Operations
12.1. Operation 15: CB_COPY - Report results of a server-side copy 12.1. Procedure 16: CB_ATTR_CHANGED - Notify Client that the File's
Attributes Changed
12.1.1. ARGUMENT 12.1.1. ARGUMENTS
struct CB_ATTR_CHANGED4args {
nfs_fh4 acca_fh;
bitmap4 acca_critical;
bitmap4 acca_info;
};
12.1.2. RESULTS
struct CB_ATTR_CHANGED4res {
nfsstat4 accr_status;
};
12.1.3. DESCRIPTION
The CB_ATTR_CHANGED callback operation is used by the server to
indicate to the client that the file's attributes have been modified
on the server. The server does not convey how the attributes have
changed, just that they have been modified. The server can inform
the client about both critical and informational attribute changes in
the bitmask arguments. The client SHOULD query the server about all
attributes set in acca_critical. For all changes reflected in
acca_info, the client can decide whether or not it wants to poll the
server.
The CB_ATTR_CHANGED callback operation with the FATTR4_SEC_LABEL set
in acca_critical is the method used by the server to indicate that
the MAC label for the file referenced by acca_fh has changed. In
many ways, the server does not care about the result returned by the
client.
12.2. Operation 15: CB_COPY - Report results of a server-side copy
12.2.1. ARGUMENT
union copy_info4 switch (nfsstat4 cca_status) { union copy_info4 switch (nfsstat4 cca_status) {
case NFS4_OK: case NFS4_OK:
void; void;
default: default:
length4 cca_bytes_copied; length4 cca_bytes_copied;
}; };
struct CB_COPY4args { struct CB_COPY4args {
nfs_fh4 cca_fh; nfs_fh4 cca_fh;
stateid4 cca_stateid; stateid4 cca_stateid;
copy_info4 cca_copy_info; copy_info4 cca_copy_info;
}; };
12.1.2. RESULT 12.2.2. RESULT
struct CB_COPY4res { struct CB_COPY4res {
nfsstat4 ccr_status; nfsstat4 ccr_status;
}; };
12.1.3. DESCRIPTION 12.2.3. DESCRIPTION
CB_COPY is used for both intra- and inter-server asynchronous copies. CB_COPY is used for both intra- and inter-server asynchronous copies.
The CB_COPY callback informs the client of the result of an The CB_COPY callback informs the client of the result of an
asynchronous server-side copy. This operation is sent by the asynchronous server-side copy. This operation is sent by the
destination server to the client in a CB_COMPOUND request. The copy destination server to the client in a CB_COMPOUND request. The copy
is identified by the filehandle and stateid arguments. The result is is identified by the filehandle and stateid arguments. The result is
indicated by the status field. If the copy failed, cca_bytes_copied indicated by the status field. If the copy failed, cca_bytes_copied
contains the number of bytes copied before the failure occurred. The contains the number of bytes copied before the failure occurred. The
cca_bytes_copied value indicates the number of bytes copied but not cca_bytes_copied value indicates the number of bytes copied but not
which specific bytes have been copied. which specific bytes have been copied.
 End of changes. 66 change blocks. 
470 lines changed or deleted 196 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/