draft-ietf-nfsv4-minorversion2-14.txt   draft-ietf-nfsv4-minorversion2-15.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft Editor Internet-Draft Editor
Intended status: Standards Track September 30, 2012 Intended status: Standards Track October 03, 2012
Expires: April 3, 2013 Expires: April 6, 2013
NFS Version 4 Minor Version 2 NFS Version 4 Minor Version 2
draft-ietf-nfsv4-minorversion2-14.txt draft-ietf-nfsv4-minorversion2-15.txt
Abstract Abstract
This Internet-Draft describes NFS version 4 minor version two, This Internet-Draft describes NFS version 4 minor version two,
focusing mainly on the protocol extensions made from NFS version 4 focusing mainly on the protocol extensions made from NFS version 4
minor version 0 and NFS version 4 minor version 1. Major extensions minor version 0 and NFS version 4 minor version 1. Major extensions
introduced in NFS version 4 minor version two include: Server-side introduced in NFS version 4 minor version two include: Server-side
Copy, Application I/O Advise, Space Reservations, Sparse Files, Copy, Application I/O Advise, Space Reservations, Sparse Files,
Application Data Blocks, and Labeled NFS. Application Data Blocks, and Labeled NFS.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 3, 2013. This Internet-Draft will expire on April 6, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 51 skipping to change at page 3, line 51
7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 33
7.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 34 7.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 34
7.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 34 7.3. MAC Security Attribute . . . . . . . . . . . . . . . . . 34
7.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 35 7.3.1. Delegations . . . . . . . . . . . . . . . . . . . . . 35
7.3.2. Permission Checking . . . . . . . . . . . . . . . . . 35 7.3.2. Permission Checking . . . . . . . . . . . . . . . . . 35
7.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 36 7.3.3. Object Creation . . . . . . . . . . . . . . . . . . . 36
7.3.4. Existing Objects . . . . . . . . . . . . . . . . . . . 36 7.3.4. Existing Objects . . . . . . . . . . . . . . . . . . . 36
7.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 36 7.3.5. Label Changes . . . . . . . . . . . . . . . . . . . . 36
7.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 37 7.4. pNFS Considerations . . . . . . . . . . . . . . . . . . . 37
7.5. Discovery of Server Labeled NFS Support . . . . . . . . . 37 7.5. Discovery of Server Labeled NFS Support . . . . . . . . . 37
7.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 38 7.6. MAC Security NFS Modes of Operation . . . . . . . . . . . 37
7.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 38 7.6.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 38
7.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 39 7.6.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 39
7.7. Security Considerations . . . . . . . . . . . . . . . . . 39 7.7. Security Considerations . . . . . . . . . . . . . . . . . 39
8. Sharing change attribute implementation details with NFSv4 8. Sharing change attribute implementation details with NFSv4
clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 40 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 41 10. Error Values . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Error Definitions . . . . . . . . . . . . . . . . . . . . 41 10.1. Error Definitions . . . . . . . . . . . . . . . . . . . . 41
10.1.1. General Errors . . . . . . . . . . . . . . . . . . . . 41 10.1.1. General Errors . . . . . . . . . . . . . . . . . . . . 41
10.1.2. Server to Server Copy Errors . . . . . . . . . . . . . 41 10.1.2. Server to Server Copy Errors . . . . . . . . . . . . . 41
10.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . . 42 10.1.3. Labeled NFS Errors . . . . . . . . . . . . . . . . . . 42
11. New File Attributes . . . . . . . . . . . . . . . . . . . . . 42 11. New File Attributes . . . . . . . . . . . . . . . . . . . . . 42
11.1. New RECOMMENDED Attributes - List and Definition 11.1. New RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 42 References . . . . . . . . . . . . . . . . . . . . . . . 42
11.2. Attribute Definitions . . . . . . . . . . . . . . . . . . 43 11.2. Attribute Definitions . . . . . . . . . . . . . . . . . . 43
12. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . . 46 12. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . . 46
13. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . . 50 13. NFSv4.2 Operations . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Operation 59: COPY - Initiate a server-side copy . . . . 50 13.1. Operation 59: COPY - Initiate a server-side copy . . . . 50
13.2. Operation 60: OFFLOAD_ABORT - Cancel a server-side 13.2. Operation 60: OFFLOAD_ABORT - Cancel a server-side
copy . . . . . . . . . . . . . . . . . . . . . . . . . . 57 copy . . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.3. Operation 61: COPY_NOTIFY - Notify a source server of 13.3. Operation 61: COPY_NOTIFY - Notify a source server of
a future copy . . . . . . . . . . . . . . . . . . . . . . 58 a future copy . . . . . . . . . . . . . . . . . . . . . . 59
13.4. Operation 62: OFFLOAD_REVOKE - Revoke a destination 13.4. Operation 62: OFFLOAD_REVOKE - Revoke a destination
server's copy privileges . . . . . . . . . . . . . . . . 60 server's copy privileges . . . . . . . . . . . . . . . . 60
13.5. Operation 63: OFFLOAD_STATUS - Poll for status of a 13.5. Operation 63: OFFLOAD_STATUS - Poll for status of a
server-side copy . . . . . . . . . . . . . . . . . . . . 61 server-side copy . . . . . . . . . . . . . . . . . . . . 61
13.6. Modification to Operation 42: EXCHANGE_ID - 13.6. Modification to Operation 42: EXCHANGE_ID -
Instantiate Client ID . . . . . . . . . . . . . . . . . . 62 Instantiate Client ID . . . . . . . . . . . . . . . . . . 63
13.7. Operation 64: INITIALIZE . . . . . . . . . . . . . . . . 63 13.7. Operation 64: INITIALIZE . . . . . . . . . . . . . . . . 64
13.8. Operation 67: IO_ADVISE - Application I/O access 13.8. Operation 67: IO_ADVISE - Application I/O access
pattern hints . . . . . . . . . . . . . . . . . . . . . . 67 pattern hints . . . . . . . . . . . . . . . . . . . . . . 67
13.9. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 72 13.9. Changes to Operation 51: LAYOUTRETURN . . . . . . . . . . 73
13.10. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 75 13.10. Operation 65: READ_PLUS . . . . . . . . . . . . . . . . . 76
13.11. Operation 66: SEEK . . . . . . . . . . . . . . . . . . . 80 13.11. Operation 66: SEEK . . . . . . . . . . . . . . . . . . . 81
14. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 81 14. NFSv4.2 Callback Operations . . . . . . . . . . . . . . . . . 82
14.1. Procedure 16: CB_ATTR_CHANGED - Notify Client that 14.1. Operation 15: CB_COPY - Report results of a
the File's Attributes Changed . . . . . . . . . . . . . . 81
14.2. Operation 15: CB_COPY - Report results of a
server-side copy . . . . . . . . . . . . . . . . . . . . 82 server-side copy . . . . . . . . . . . . . . . . . . . . 82
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83
16.1. Normative References . . . . . . . . . . . . . . . . . . 84 16.1. Normative References . . . . . . . . . . . . . . . . . . 83
16.2. Informative References . . . . . . . . . . . . . . . . . 85 16.2. Informative References . . . . . . . . . . . . . . . . . 84
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 86 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 85
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 87 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 86
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
1.1. The NFS Version 4 Minor Version 2 Protocol 1.1. The NFS Version 4 Minor Version 2 Protocol
The NFS version 4 minor version 2 (NFSv4.2) protocol is the third The NFS version 4 minor version 2 (NFSv4.2) protocol is the third
minor version of the NFS version 4 (NFSv4) protocol. The first minor minor version of the NFS version 4 (NFSv4) protocol. The first minor
version, NFSv4.0, is described in [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 [10]. versioning that are listed in Section 11 of [10].
skipping to change at page 8, line 22 skipping to change at page 8, line 22
COPY: Used by the client to request a file copy. (Section 13.1) COPY: Used by the client to request a file copy. (Section 13.1)
OFFLOAD_ABORT: Used by the client to abort an asynchronous file OFFLOAD_ABORT: Used by the client to abort an asynchronous file
copy. (Section 13.2) copy. (Section 13.2)
OFFLOAD_STATUS: Used by the client to poll the status of an OFFLOAD_STATUS: Used by the client to poll the status of an
asynchronous file copy. (Section 13.5) asynchronous file copy. (Section 13.5)
CB_COPY: Used by the destination server to report the results of an CB_COPY: Used by the destination server to report the results of an
asynchronous file copy to the client. (Section 14.2) asynchronous file copy to the client. (Section 14.1)
2.2.2. Locking the Files 2.2.2. Locking the Files
Both the source and destination file may need to be locked to protect Both the source and destination file may need to be locked to protect
the content during the copy operations. A client can achieve this by the content during the copy operations. A client can achieve this by
a combination of OPEN and LOCK operations. I.e., either share or a combination of OPEN and LOCK operations. I.e., either share or
byte range locks might be desired. byte range locks might be desired.
2.2.3. Intra-Server Copy 2.2.3. Intra-Server Copy
skipping to change at page 27, line 28 skipping to change at page 27, line 28
machine from continuing execution and result in downtime. machine from continuing execution and result in downtime.
Currently, in order to achieve such a guarantee, applications zero Currently, in order to achieve such a guarantee, applications zero
the entire file. The initial zeroing allocates the backing blocks the entire file. The initial zeroing allocates the backing blocks
and all subsequent writes are overwrites of already allocated blocks. and all subsequent writes are overwrites of already allocated blocks.
This approach is not only inefficient in terms of the amount of I/O This approach is not only inefficient in terms of the amount of I/O
done, it is also not guaranteed to work on file systems that are log done, it is also not guaranteed to work on file systems that are log
structured or deduplicated. An efficient way of guaranteeing space structured or deduplicated. An efficient way of guaranteeing space
reservation would be beneficial to such applications. reservation would be beneficial to such applications.
If the space_reserved attribute (see Section 11.2.3) is set on a If the space_reserved attribute (see Section 11.2.4) is set on a
file, it is guaranteed that writes that do not grow the file will not file, it is guaranteed that writes that do not grow the file will not
fail with NFSERR_NOSPC. fail with NFSERR_NOSPC.
Another useful feature would be the ability to report the number of Another useful feature would be the ability to report the number of
blocks that would be freed when a file is deleted. Currently, NFS blocks that would be freed when a file is deleted. Currently, NFS
reports two size attributes: reports two size attributes:
size The logical file size of the file. size The logical file size of the file.
space_used The size in bytes that the file occupies on disk space_used The size in bytes that the file occupies on disk
skipping to change at page 28, line 39 skipping to change at page 28, line 39
reporting of the space utilization. reporting of the space utilization.
For example, two files A and B have 10 blocks each. Let 6 of these For example, two files A and B have 10 blocks each. Let 6 of these
blocks be shared between them. Thus, the combined space utilized by blocks be shared between them. Thus, the combined space utilized by
the two files is 14 * BLOCK_SIZE bytes. In the former case, the the two files is 14 * BLOCK_SIZE bytes. In the former case, the
combined space utilization of the two files would be reported as 20 * combined space utilization of the two files would be reported as 20 *
BLOCK_SIZE. However, deleting either would only result in 4 * BLOCK_SIZE. However, deleting either would only result in 4 *
BLOCK_SIZE being freed. Conversely, the latter interpretation would BLOCK_SIZE being freed. Conversely, the latter interpretation would
report that the space utilization is only 8 * BLOCK_SIZE. report that the space utilization is only 8 * BLOCK_SIZE.
Adding another size attribute, space_freed (see Section 11.2.4), is Adding another size attribute, space_freed (see Section 11.2.5), is
helpful in solving this problem. space_freed is the number of blocks helpful in solving this problem. space_freed is the number of blocks
that are allocated to the given file that would be freed on its that are allocated to the given file that would be freed on its
deletion. In the example, both A and B would report space_freed as 4 deletion. In the example, both A and B would report space_freed as 4
* BLOCK_SIZE and space_used as 10 * BLOCK_SIZE. If A is deleted, B * BLOCK_SIZE and space_used as 10 * BLOCK_SIZE. If A is deleted, B
will report space_freed as 10 * BLOCK_SIZE as the deletion of B would will report space_freed as 10 * BLOCK_SIZE as the deletion of B would
result in the deallocation of all 10 blocks. result in the deallocation of all 10 blocks.
The addition of this problem doesn't solve the problem of space being The addition of this problem doesn't solve the problem of space being
over-reported. However, over-reporting is better than under- over-reported. However, over-reporting is better than under-
reporting. reporting.
skipping to change at page 33, line 35 skipping to change at page 33, line 35
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
additional policy on what subjects may modify security label additional policy on what subjects may modify security label
information. information.
The second change is to provide a method for the server to notify the The second change is to provide methods for the client to determine
client that the attribute changed on an open file on the server. If if the security label has changed. A client which needs to know if a
the file is closed, then during the open attempt, the client will label is going to change SHOULD register a delegation on that file.
gather the new attribute value. The server MUST not communicate the In order to change the security label, the server will have to recall
new value of the attribute, the client MUST query it. This all delegations. This will inform the client of the change. If a
requirement stems from the need for the client to provide sufficient client wants to detect if the label has changed, it MAY use VERIFY
access rights to the attribute. and NVERIFY on FATTR4_CHANGE_SEC_LABEL to detect that the
FATTR4_SEC_LABEL has been modified.
The final change necessary is a modification to the RPC layer used in The final change necessary is a modification to the RPC layer used in
NFSv4 in the form of a new version of the RPCSEC_GSS [8] framework. NFSv4 in the form of a new version of the RPCSEC_GSS [8] framework.
In order for an NFSv4 server to apply MAC checks it must obtain In order for an NFSv4 server to apply MAC checks it must obtain
additional information from the client. Several methods were additional information from the client. Several methods were
explored for performing this and it was decided that the best explored for performing this and it was decided that the best
approach was to incorporate the ability to make security attribute approach was to incorporate the ability to make security attribute
assertions through the RPC mechanism. RPCSECGSSv3 [5] outlines a assertions through the RPC mechanism. RPCSECGSSv3 [5] outlines a
method to assert additional security information such as security method to assert additional security information such as security
labels on gss context creation and have that data bound to all RPC labels on gss context creation and have that data bound to all RPC
skipping to change at page 36, line 28 skipping to change at page 36, line 28
7.3.4. Existing Objects 7.3.4. 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 Labeled NFS Therefore, if an existing server is upgraded to include Labeled NFS
support, then it is the responsibility of the security system to support, then it is the responsibility of the security system to
define the behavior for existing objects. define the behavior for existing objects.
7.3.5. Label Changes 7.3.5. Label Changes
As per the requirements, when a file's security label is modified,
the server must notify all clients which have the file opened of the
change in label. It does so with CB_ATTR_CHANGED. There are
preconditions to making an attribute change imposed by NFSv4 and the
security system might want to impose others. In the process of
meeting these preconditions, the server may chose to either serve the
request in whole or return NFS4ERR_DELAY to the SETATTR operation.
If there are open delegations on the file belonging to client other If there are open delegations on the file belonging to client other
than the one making the label change, then the process described in than the one making the label change, then the process described in
Section 7.3.1 must be followed. Section 7.3.1 must be followed. In short, the delegation will be
recalled, which effectively notifies the client of the change.
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.
the client may share the same object between multiple subjects or a
security system which is not strictly hierarchical that the
CB_ATTR_CHANGED callback is very useful. It allows the server to
inform the clients that the cached security attribute is now stale.
Consider a system in which the clients enforce MAC checks and and the Consider a system in which the clients enforce MAC checks and and the
server has a very simple security system which just stores the server has a very simple security system which just stores the
labels. In this system, the MAC label check always allows access, labels. In this system, the MAC label check always allows access,
regardless of the subject label. regardless of the subject label.
The way in which MAC labels are enforced is by the client. So if The way in which MAC labels are enforced is by the client. The
client A changes a security label on a file, then the server MUST security policies on the client can be such that the client does not
inform all clients that have the file opened that the label has have access to the file unless it has a delegation. The recall of
changed via CB_ATTR_CHANGED. Then the clients MUST retrieve the new the delegation will force the client to flush any cached content of
label and MUST enforce access via the new attribute values. the file. The clients could also be configured to periodically
VERIFY/NVERIFY the FATTR4_CHANGE_SEC_LABEL attribute to determine
when the label has changed. When a change is detected, then the
client could take the costlier action of retrieving the
FATTR4_SEC_LABEL.
7.4. pNFS Considerations 7.4. pNFS Considerations
This section examines the issues in deploying Labeled NFS in a pNFS This section examines the issues in deploying Labeled NFS in a pNFS
community of servers. community of servers.
7.4.1. MAC Label Checks 7.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
CB_ATTR_CHANGED to inform the client of that fact. If the MDS is
maintaining [[Comment.2: Houston, we seem to have a problem! --TH]]
7.5. Discovery of Server Labeled NFS Support 7.5. Discovery of Server Labeled NFS Support
The server can easily determine that a client supports Labeled NFS The server can easily determine that a client supports Labeled NFS
when it queries for the FATTR4_SEC_LABEL label for an object. Note when it queries for the FATTR4_SEC_LABEL label for an object. Note
that it cannot assume that the presence of RPCSEC_GSSv3 indicates that it cannot assume that the presence of RPCSEC_GSSv3 indicates
Labeled NFS support. The client might need to discover which LFS the Labeled NFS support. The client might need to discover which LFS the
server supports. server supports.
A server which supports Labeled NFS MUST allow a client with any A server which supports Labeled NFS MUST allow a client with any
subject label to retrieve the FATTR4_SEC_LABEL attribute for the root subject label to retrieve the FATTR4_SEC_LABEL attribute for the root
skipping to change at page 39, line 28 skipping to change at page 39, line 18
network to ensure that they are within a set of attributes permitted network to ensure that they are within a set of attributes permitted
from a specific peer, and if not, reject them. Note that a system from a specific peer, and if not, reject them. Note that a system
may permit a different set of attributes to be accepted from each may permit a different set of attributes to be accepted from each
peer. peer.
7.6.1.3. Limited Server 7.6.1.3. Limited Server
A Limited Server mode (see Section 3.5.2 of [7]) consists of a server A Limited Server mode (see Section 3.5.2 of [7]) consists of a server
which is label aware, but does not enforce policies. Such a server which is label aware, but does not enforce policies. Such a server
will store and retrieve all object labels presented by clients, will store and retrieve all object labels presented by clients,
notify the clients of any label changes via CB_ATTR_CHANGED, but will utililze the methods described in Section 7.3.5 to allow the clients
not restrict access via the subject label. Instead, it will expect to detect changing labels,, but will not restrict access via the
the clients to enforce all such access locally. subject label. Instead, it will expect the clients to enforce all
such access locally.
7.6.2. Guest Mode 7.6.2. Guest Mode
Guest mode implies that either the client or the server does not Guest mode implies that either the client or the server does not
handle labels. If the client is not Labeled NFS aware, then it will handle labels. If the client is not Labeled NFS aware, then it will
not offer subject labels to the server. The server is the only not offer subject labels to the server. The server is the only
entity enforcing policy, and may selectively provide standard NFS entity enforcing policy, and may selectively provide standard NFS
services to clients based on their authentication credentials and/or services to clients based on their authentication credentials and/or
associated network attributes (e.g., IP address, network interface). associated network attributes (e.g., IP address, network interface).
The level of trust and access extended to a client in this mode is The level of trust and access extended to a client in this mode is
skipping to change at page 43, line 30 skipping to change at page 43, line 19
R W means read/write (GETATTR may retrieve, SETATTR may set). R W means read/write (GETATTR may retrieve, SETATTR may set).
Defined in: The section of this specification that describes the Defined in: The section of this specification that describes the
attribute. attribute.
+------------------+----+-------------------+-----+----------------+ +------------------+----+-------------------+-----+----------------+
| Name | Id | Data Type | Acc | Defined in | | Name | Id | Data Type | Acc | Defined in |
+------------------+----+-------------------+-----+----------------+ +------------------+----+-------------------+-----+----------------+
| change_attr_type | 79 | change_attr_type4 | R | Section 11.2.1 | | change_attr_type | 79 | change_attr_type4 | R | Section 11.2.1 |
| sec_label | 80 | sec_label4 | R W | Section 11.2.2 | | sec_label | 80 | sec_label4 | R W | Section 11.2.2 |
| space_reserved | 77 | boolean | R W | Section 11.2.3 | | change_sec_label | 81 | change_sec_label4 | R | Section 11.2.3 |
| space_freed | 78 | length4 | R | Section 11.2.4 | | space_reserved | 77 | boolean | R W | Section 11.2.4 |
| space_freed | 78 | length4 | R | Section 11.2.5 |
+------------------+----+-------------------+-----+----------------+ +------------------+----+-------------------+-----+----------------+
Table 2 Table 2
11.2. Attribute Definitions 11.2. Attribute Definitions
11.2.1. Attribute 79: change_attr_type 11.2.1. Attribute 79: change_attr_type
enum change_attr_type4 { enum change_attr_type4 {
NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR = 0, NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR = 0,
skipping to change at page 45, line 39 skipping to change at page 45, line 33
is an opaque section which contains the data of the attribute. This is an opaque section which contains the data of the attribute. This
component is dependent on the MAC model to interpret and enforce. component is dependent on the MAC model to interpret and enforce.
In particular, it is the responsibility of the LFS specification to In particular, it is the responsibility of the LFS specification to
define a maximum size for the opaque section, slai_data<>. When define a maximum size for the opaque section, slai_data<>. When
creating or modifying a label for an object, the client needs to be creating or modifying a label for an object, the client needs to be
guaranteed that the server will accept a label that is sized guaranteed that the server will accept a label that is sized
correctly. By both client and server being part of a specific MAC correctly. By both client and server being part of a specific MAC
model, the client will be aware of the size. model, the client will be aware of the size.
11.2.3. Attribute 77: space_reserved 11.2.3. Attribute 81: change_sec_label
typedef uint32_t change_sec_label4;
The change_sec_label attribute is a read-only attribute per file.
When the file is created, the value of change_sec_label is set to 0.
Each time the sec_label is changed, the server MUST increment the
value of change_sec_label by one. As the sec_label is not bounded by
size, this attribute allows for VERIFY and NVERIFY to quickly
determine if the sec_label has been modified.
11.2.4. Attribute 77: space_reserved
The space_reserve attribute is a read/write attribute of type The space_reserve attribute is a read/write attribute of type
boolean. It is a per file attribute. When the space_reserved boolean. It is a per file attribute. When the space_reserved
attribute is set via SETATTR, the server must ensure that there is attribute is set via SETATTR, the server must ensure that there is
disk space to accommodate every byte in the file before it can return disk space to accommodate every byte in the file before it can return
success. If the server cannot guarantee this, it must return success. If the server cannot guarantee this, it must return
NFS4ERR_NOSPC. NFS4ERR_NOSPC.
If the client tries to grow a file which has the space_reserved If the client tries to grow a file which has the space_reserved
attribute set, the server must guarantee that there is disk space to attribute set, the server must guarantee that there is disk space to
skipping to change at page 46, line 21 skipping to change at page 46, line 26
The value of space_reserved can be obtained at any time through The value of space_reserved can be obtained at any time through
GETATTR. GETATTR.
In order to avoid ambiguity, the space_reserve bit cannot be set In order to avoid ambiguity, the space_reserve bit cannot be set
along with the size bit in SETATTR. Increasing the size of a file along with the size bit in SETATTR. Increasing the size of a file
with space_reserve set will fail if space reservation cannot be with space_reserve set will fail if space reservation cannot be
guaranteed for the new size. If the file size is decreased, space guaranteed for the new size. If the file size is decreased, space
reservation is only guaranteed for the new size and the extra blocks reservation is only guaranteed for the new size and the extra blocks
backing the file can be released. backing the file can be released.
11.2.4. Attribute 78: space_freed 11.2.5. Attribute 78: space_freed
space_freed gives the number of bytes freed if the file is deleted. space_freed gives the number of bytes freed if the file is deleted.
This attribute is read only and is of type length4. It is a per file This attribute is read only and is of type length4. It is a per file
attribute. attribute.
12. Operations: REQUIRED, RECOMMENDED, or OPTIONAL 12. Operations: REQUIRED, RECOMMENDED, or OPTIONAL
The following tables summarize the operations of the NFSv4.2 protocol The following tables summarize the operations of the NFSv4.2 protocol
and the corresponding designation of REQUIRED, RECOMMENDED, and and the corresponding designation of REQUIRED, RECOMMENDED, and
OPTIONAL to implement or either OBSOLETE if implemented or MUST NOT OPTIONAL to implement or either OBSOLETE if implemented or MUST NOT
skipping to change at page 81, line 46 skipping to change at page 82, line 21
SEEK must follow the same rules for stateids as READ_PLUS SEEK must follow the same rules for stateids as READ_PLUS
(Section 13.10.3). (Section 13.10.3).
If the server could not find a corresponding sa_what, then the status If the server could not find a corresponding sa_what, then the status
would still be NFS4_OK, but sr_eof would be TRUE. The sr_contents would still be NFS4_OK, but sr_eof would be TRUE. The sr_contents
would contain a zero-ed out content of the appropriate type. would contain a zero-ed out content of the appropriate type.
14. NFSv4.2 Callback Operations 14. NFSv4.2 Callback Operations
14.1. Procedure 16: CB_ATTR_CHANGED - Notify Client that the File's 14.1. Operation 15: CB_COPY - Report results of a server-side copy
Attributes Changed
14.1.1. ARGUMENTS
struct CB_ATTR_CHANGED4args {
nfs_fh4 acca_fh;
bitmap4 acca_critical;
bitmap4 acca_info;
};
14.1.2. RESULTS
struct CB_ATTR_CHANGED4res {
nfsstat4 accr_status;
};
14.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.
14.2. Operation 15: CB_COPY - Report results of a server-side copy 14.1.1. ARGUMENT
14.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;
}; };
14.2.2. RESULT 14.1.2. RESULT
struct CB_COPY4res { struct CB_COPY4res {
nfsstat4 ccr_status; nfsstat4 ccr_status;
}; };
14.2.3. DESCRIPTION 14.1.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. 27 change blocks. 
102 lines changed or deleted 69 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/