Found wdiff, but it reported no recognisable version. Falling back to builtin diff colouring...
draft-pre-ch-18-rename.txt | draft-ietf-nfsv4-minorversion1-22.txt | |||
---|---|---|---|---|
NFSv4 S. Shepler | NFSv4 S. Shepler | |||
Internet-Draft M. Eisler | Internet-Draft M. Eisler | |||
Intended status: Standards Track D. Noveck | Intended status: Standards Track D. Noveck | |||
Expires: October 13, 2008 Editors | Expires: October 19, 2008 Editors | |||
April 11, 2008 | April 17, 2008 | |||
NFS Version 4 Minor Version 1 | NFS Version 4 Minor Version 1 | |||
draft-ietf-nfsv4-minorversion1-22.txt | draft-ietf-nfsv4-minorversion1-22.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on October 13, 2008. | This Internet-Draft will expire on October 19, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
Abstract | Abstract | |||
This Internet-Draft describes NFS version 4 minor version one, | This Internet-Draft describes NFS version 4 minor version one, | |||
including features retained from the base protocol and protocol | including features retained from the base protocol and protocol | |||
extensions made subsequently. Major extensions introduced in NFS | extensions made subsequently. Major extensions introduced in NFS | |||
skipping to change at page 2, line 39 | skipping to change at page 2, line 39 | |||
2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 22 | 2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 22 | |||
2.4. Client Identifiers and Client Owners . . . . . . . . . . 23 | 2.4. Client Identifiers and Client Owners . . . . . . . . . . 23 | |||
2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 27 | 2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 27 | |||
2.4.2. Server Release of Client ID . . . . . . . . . . . . 27 | 2.4.2. Server Release of Client ID . . . . . . . . . . . . 27 | |||
2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 27 | 2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 27 | |||
2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 29 | 2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 29 | |||
2.6. Security Service Negotiation . . . . . . . . . . . . . . 29 | 2.6. Security Service Negotiation . . . . . . . . . . . . . . 29 | |||
2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 30 | 2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 30 | |||
2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 30 | 2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 30 | |||
2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 30 | 2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 30 | |||
2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 33 | 2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 35 | |||
2.8. Non-RPC-based Security Services . . . . . . . . . . . . 36 | 2.8. Non-RPC-based Security Services . . . . . . . . . . . . 37 | |||
2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 36 | 2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 37 | |||
2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 36 | 2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 38 | |||
2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 37 | 2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 38 | |||
2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 37 | 2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 38 | |||
2.9.1. REQUIRED and RECOMMENDED Properties of Transports . 37 | 2.9.1. REQUIRED and RECOMMENDED Properties of Transports . 38 | |||
2.9.2. Client and Server Transport Behavior . . . . . . . . 37 | 2.9.2. Client and Server Transport Behavior . . . . . . . . 39 | |||
2.9.3. Ports . . . . . . . . . . . . . . . . . . . . . . . 39 | 2.9.3. Ports . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . 39 | 2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
2.10.1. Motivation and Overview . . . . . . . . . . . . . . 39 | 2.10.1. Motivation and Overview . . . . . . . . . . . . . . 40 | |||
2.10.2. NFSv4 Integration . . . . . . . . . . . . . . . . . 40 | 2.10.2. NFSv4 Integration . . . . . . . . . . . . . . . . . 42 | |||
2.10.3. Channels . . . . . . . . . . . . . . . . . . . . . . 42 | 2.10.3. Channels . . . . . . . . . . . . . . . . . . . . . . 43 | |||
2.10.4. Trunking . . . . . . . . . . . . . . . . . . . . . . 43 | 2.10.4. Trunking . . . . . . . . . . . . . . . . . . . . . . 44 | |||
2.10.5. Exactly Once Semantics . . . . . . . . . . . . . . . 46 | 2.10.5. Exactly Once Semantics . . . . . . . . . . . . . . . 47 | |||
2.10.6. RDMA Considerations . . . . . . . . . . . . . . . . 59 | 2.10.6. RDMA Considerations . . . . . . . . . . . . . . . . 60 | |||
2.10.7. Sessions Security . . . . . . . . . . . . . . . . . 62 | 2.10.7. Sessions Security . . . . . . . . . . . . . . . . . 63 | |||
2.10.8. The SSV GSS Mechanism . . . . . . . . . . . . . . . 67 | 2.10.8. The SSV GSS Mechanism . . . . . . . . . . . . . . . 68 | |||
2.10.9. Session Mechanics - Steady State . . . . . . . . . . 71 | 2.10.9. Session Mechanics - Steady State . . . . . . . . . . 72 | |||
2.10.10. Session Inactivity Timer . . . . . . . . . . . . . . 73 | 2.10.10. Session Inactivity Timer . . . . . . . . . . . . . . 74 | |||
2.10.11. Session Mechanics - Recovery . . . . . . . . . . . . 73 | 2.10.11. Session Mechanics - Recovery . . . . . . . . . . . . 74 | |||
2.10.12. Parallel NFS and Sessions . . . . . . . . . . . . . 77 | 2.10.12. Parallel NFS and Sessions . . . . . . . . . . . . . 78 | |||
3. Protocol Constants and Data Types . . . . . . . . . . . . . . 77 | 3. Protocol Constants and Data Types . . . . . . . . . . . . . . 78 | |||
3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . 77 | 3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . 78 | |||
3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 78 | 3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 79 | |||
3.3. Structured Data Types . . . . . . . . . . . . . . . . . 80 | 3.3. Structured Data Types . . . . . . . . . . . . . . . . . 81 | |||
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 89 | 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 90 | |||
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 89 | 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 90 | |||
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 90 | 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 91 | |||
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 90 | 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 91 | |||
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 90 | 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 91 | |||
4.2.1. General Properties of a Filehandle . . . . . . . . . 91 | 4.2.1. General Properties of a Filehandle . . . . . . . . . 92 | |||
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 92 | 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 93 | |||
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 92 | 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 93 | |||
4.3. One Method of Constructing a Volatile Filehandle . . . . 93 | 4.3. One Method of Constructing a Volatile Filehandle . . . . 94 | |||
4.4. Client Recovery from Filehandle Expiration . . . . . . . 94 | 4.4. Client Recovery from Filehandle Expiration . . . . . . . 95 | |||
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 95 | 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 96 | |||
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 96 | 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 97 | |||
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 96 | 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 97 | |||
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 97 | 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 98 | |||
5.4. Classification of Attributes . . . . . . . . . . . . . . 98 | 5.4. Classification of Attributes . . . . . . . . . . . . . . 99 | |||
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 99 | 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 100 | |||
5.6. REQUIRED Attributes - List and Definition References . . 99 | 5.6. REQUIRED Attributes - List and Definition References . . 100 | |||
5.7. RECOMMENDED Attributes - List and Definition | 5.7. RECOMMENDED Attributes - List and Definition | |||
References . . . . . . . . . . . . . . . . . . . . . . . 100 | References . . . . . . . . . . . . . . . . . . . . . . . 101 | |||
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 102 | 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 103 | |||
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 102 | 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 103 | |||
5.8.2. Definitions of Uncategorized RECOMMENDED | 5.8.2. Definitions of Uncategorized RECOMMENDED | |||
Attributes . . . . . . . . . . . . . . . . . . . . . 104 | Attributes . . . . . . . . . . . . . . . . . . . . . 105 | |||
5.9. Interpreting owner and owner_group . . . . . . . . . . . 111 | 5.9. Interpreting owner and owner_group . . . . . . . . . . . 112 | |||
5.10. Character Case Attributes . . . . . . . . . . . . . . . 113 | 5.10. Character Case Attributes . . . . . . . . . . . . . . . 114 | |||
5.11. Directory Notification Attributes . . . . . . . . . . . 113 | 5.11. Directory Notification Attributes . . . . . . . . . . . 114 | |||
5.12. pNFS Attribute Definitions . . . . . . . . . . . . . . . 113 | 5.12. pNFS Attribute Definitions . . . . . . . . . . . . . . . 114 | |||
5.13. Retention Attributes . . . . . . . . . . . . . . . . . . 115 | 5.13. Retention Attributes . . . . . . . . . . . . . . . . . . 116 | |||
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 118 | 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 119 | |||
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 118 | 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 119 | |||
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 119 | 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 120 | |||
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 119 | 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 120 | |||
6.2.2. Attribute 58: dacl . . . . . . . . . . . . . . . . . 134 | 6.2.2. Attribute 58: dacl . . . . . . . . . . . . . . . . . 135 | |||
6.2.3. Attribute 59: sacl . . . . . . . . . . . . . . . . . 134 | 6.2.3. Attribute 59: sacl . . . . . . . . . . . . . . . . . 135 | |||
6.2.4. Attribute 33: mode . . . . . . . . . . . . . . . . . 134 | 6.2.4. Attribute 33: mode . . . . . . . . . . . . . . . . . 135 | |||
6.2.5. Attribute 74: mode_set_masked . . . . . . . . . . . 135 | 6.2.5. Attribute 74: mode_set_masked . . . . . . . . . . . 136 | |||
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 136 | 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 137 | |||
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 136 | 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 137 | |||
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 137 | 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 138 | |||
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 138 | 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 139 | |||
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 138 | 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 139 | |||
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 140 | 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 141 | |||
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 140 | 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 141 | |||
7. Single-server Namespace . . . . . . . . . . . . . . . . . . . 144 | 7. Single-server Namespace . . . . . . . . . . . . . . . . . . . 145 | |||
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 144 | 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 145 | |||
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 145 | 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 146 | |||
7.3. Server Pseudo File System . . . . . . . . . . . . . . . 145 | 7.3. Server Pseudo File System . . . . . . . . . . . . . . . 146 | |||
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 146 | 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 147 | |||
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 146 | 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 147 | |||
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 146 | 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 147 | |||
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 147 | 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 148 | |||
7.8. Security Policy and Namespace Presentation . . . . . . . 147 | 7.8. Security Policy and Namespace Presentation . . . . . . . 148 | |||
8. State Management . . . . . . . . . . . . . . . . . . . . . . 148 | 8. State Management . . . . . . . . . . . . . . . . . . . . . . 149 | |||
8.1. Client and Session ID . . . . . . . . . . . . . . . . . 149 | 8.1. Client and Session ID . . . . . . . . . . . . . . . . . 150 | |||
8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 149 | 8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 150 | |||
8.2.1. Stateid Types . . . . . . . . . . . . . . . . . . . 150 | 8.2.1. Stateid Types . . . . . . . . . . . . . . . . . . . 151 | |||
8.2.2. Stateid Structure . . . . . . . . . . . . . . . . . 151 | 8.2.2. Stateid Structure . . . . . . . . . . . . . . . . . 152 | |||
8.2.3. Special Stateids . . . . . . . . . . . . . . . . . . 152 | 8.2.3. Special Stateids . . . . . . . . . . . . . . . . . . 153 | |||
8.2.4. Stateid Lifetime and Validation . . . . . . . . . . 154 | 8.2.4. Stateid Lifetime and Validation . . . . . . . . . . 155 | |||
8.2.5. Stateid Use for I/O Operations . . . . . . . . . . . 157 | 8.2.5. Stateid Use for I/O Operations . . . . . . . . . . . 158 | |||
8.2.6. Stateid Use for SETATTR Operations . . . . . . . . . 158 | 8.2.6. Stateid Use for SETATTR Operations . . . . . . . . . 159 | |||
8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 158 | 8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 159 | |||
8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 160 | 8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 161 | |||
8.4.1. Client Failure and Recovery . . . . . . . . . . . . 161 | 8.4.1. Client Failure and Recovery . . . . . . . . . . . . 162 | |||
8.4.2. Server Failure and Recovery . . . . . . . . . . . . 161 | 8.4.2. Server Failure and Recovery . . . . . . . . . . . . 162 | |||
8.4.3. Network Partitions and Recovery . . . . . . . . . . 165 | 8.4.3. Network Partitions and Recovery . . . . . . . . . . 166 | |||
8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 170 | 8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 171 | |||
8.6. Short and Long Leases . . . . . . . . . . . . . . . . . 171 | 8.6. Short and Long Leases . . . . . . . . . . . . . . . . . 172 | |||
8.7. Clocks, Propagation Delay, and Calculating Lease | 8.7. Clocks, Propagation Delay, and Calculating Lease | |||
Expiration . . . . . . . . . . . . . . . . . . . . . . . 171 | Expiration . . . . . . . . . . . . . . . . . . . . . . . 172 | |||
8.8. Obsolete Locking Infrastructure From NFSv4.0 . . . . . . 172 | 8.8. Obsolete Locking Infrastructure From NFSv4.0 . . . . . . 173 | |||
9. File Locking and Share Reservations . . . . . . . . . . . . . 173 | 9. File Locking and Share Reservations . . . . . . . . . . . . . 174 | |||
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 173 | 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 174 | |||
9.1.1. State-owner Definition . . . . . . . . . . . . . . . 173 | 9.1.1. State-owner Definition . . . . . . . . . . . . . . . 174 | |||
9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 174 | 9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 175 | |||
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 177 | 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 178 | |||
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 177 | 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 178 | |||
9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 178 | 9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 179 | |||
9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 178 | 9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 179 | |||
9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 179 | 9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 180 | |||
9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 180 | 9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 181 | |||
9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 180 | 9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 181 | |||
9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 181 | 9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 182 | |||
9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 182 | 9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 183 | |||
9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 183 | 9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 184 | |||
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 183 | 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 184 | |||
10.1. Performance Challenges for Client-Side Caching . . . . . 184 | 10.1. Performance Challenges for Client-Side Caching . . . . . 185 | |||
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 185 | 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 186 | |||
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 187 | 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 188 | |||
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 189 | 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 190 | |||
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 189 | 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 190 | |||
10.3.2. Data Caching and File Locking . . . . . . . . . . . 190 | 10.3.2. Data Caching and File Locking . . . . . . . . . . . 191 | |||
10.3.3. Data Caching and Mandatory File Locking . . . . . . 192 | 10.3.3. Data Caching and Mandatory File Locking . . . . . . 193 | |||
10.3.4. Data Caching and File Identity . . . . . . . . . . . 192 | 10.3.4. Data Caching and File Identity . . . . . . . . . . . 193 | |||
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 194 | 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 195 | |||
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 196 | 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 197 | |||
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 197 | 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 198 | |||
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 198 | 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 199 | |||
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 201 | 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 202 | |||
10.4.5. Clients that Fail to Honor Delegation Recalls . . . 203 | 10.4.5. Clients that Fail to Honor Delegation Recalls . . . 204 | |||
10.4.6. Delegation Revocation . . . . . . . . . . . . . . . 203 | 10.4.6. Delegation Revocation . . . . . . . . . . . . . . . 204 | |||
10.4.7. Delegations via WANT_DELEGATION . . . . . . . . . . 204 | 10.4.7. Delegations via WANT_DELEGATION . . . . . . . . . . 205 | |||
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 205 | 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 206 | |||
10.5.1. Revocation Recovery for Write Open Delegation . . . 205 | 10.5.1. Revocation Recovery for Write Open Delegation . . . 206 | |||
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 206 | 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 207 | |||
10.7. Data and Metadata Caching and Memory Mapped Files . . . 208 | 10.7. Data and Metadata Caching and Memory Mapped Files . . . 209 | |||
10.8. Name and Directory Caching without Directory | 10.8. Name and Directory Caching without Directory | |||
Delegations . . . . . . . . . . . . . . . . . . . . . . 210 | Delegations . . . . . . . . . . . . . . . . . . . . . . 211 | |||
10.8.1. Name Caching . . . . . . . . . . . . . . . . . . . . 210 | 10.8.1. Name Caching . . . . . . . . . . . . . . . . . . . . 211 | |||
10.8.2. Directory Caching . . . . . . . . . . . . . . . . . 212 | 10.8.2. Directory Caching . . . . . . . . . . . . . . . . . 213 | |||
10.9. Directory Delegations . . . . . . . . . . . . . . . . . 213 | 10.9. Directory Delegations . . . . . . . . . . . . . . . . . 214 | |||
10.9.1. Introduction to Directory Delegations . . . . . . . 213 | 10.9.1. Introduction to Directory Delegations . . . . . . . 214 | |||
10.9.2. Directory Delegation Design . . . . . . . . . . . . 214 | 10.9.2. Directory Delegation Design . . . . . . . . . . . . 215 | |||
10.9.3. Attributes in Support of Directory Notifications . . 215 | 10.9.3. Attributes in Support of Directory Notifications . . 216 | |||
10.9.4. Directory Delegation Recall . . . . . . . . . . . . 215 | 10.9.4. Directory Delegation Recall . . . . . . . . . . . . 216 | |||
10.9.5. Directory Delegation Recovery . . . . . . . . . . . 216 | 10.9.5. Directory Delegation Recovery . . . . . . . . . . . 217 | |||
11. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 216 | 11. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 217 | |||
11.1. Location Attributes . . . . . . . . . . . . . . . . . . 216 | 11.1. Location Attributes . . . . . . . . . . . . . . . . . . 217 | |||
11.2. File System Presence or Absence . . . . . . . . . . . . 217 | 11.2. File System Presence or Absence . . . . . . . . . . . . 218 | |||
11.3. Getting Attributes for an Absent File System . . . . . . 218 | 11.3. Getting Attributes for an Absent File System . . . . . . 219 | |||
11.3.1. GETATTR Within an Absent File System . . . . . . . . 218 | 11.3.1. GETATTR Within an Absent File System . . . . . . . . 219 | |||
11.3.2. READDIR and Absent File Systems . . . . . . . . . . 219 | 11.3.2. READDIR and Absent File Systems . . . . . . . . . . 220 | |||
11.4. Uses of Location Information . . . . . . . . . . . . . . 220 | 11.4. Uses of Location Information . . . . . . . . . . . . . . 221 | |||
11.4.1. File System Replication . . . . . . . . . . . . . . 221 | 11.4.1. File System Replication . . . . . . . . . . . . . . 222 | |||
11.4.2. File System Migration . . . . . . . . . . . . . . . 221 | 11.4.2. File System Migration . . . . . . . . . . . . . . . 222 | |||
11.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 223 | 11.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 224 | |||
11.5. Location Entries and Server Identity . . . . . . . . . . 224 | 11.5. Location Entries and Server Identity . . . . . . . . . . 225 | |||
11.6. Additional Client-side Considerations . . . . . . . . . 225 | 11.6. Additional Client-side Considerations . . . . . . . . . 226 | |||
11.7. Effecting File System Transitions . . . . . . . . . . . 225 | 11.7. Effecting File System Transitions . . . . . . . . . . . 226 | |||
11.7.1. File System Transitions and Simultaneous Access . . 227 | 11.7.1. File System Transitions and Simultaneous Access . . 228 | |||
11.7.2. Simultaneous Use and Transparent Transitions . . . . 227 | 11.7.2. Simultaneous Use and Transparent Transitions . . . . 228 | |||
11.7.3. Filehandles and File System Transitions . . . . . . 230 | 11.7.3. Filehandles and File System Transitions . . . . . . 231 | |||
11.7.4. Fileids and File System Transitions . . . . . . . . 230 | 11.7.4. Fileids and File System Transitions . . . . . . . . 231 | |||
11.7.5. Fsids and File System Transitions . . . . . . . . . 232 | 11.7.5. Fsids and File System Transitions . . . . . . . . . 233 | |||
11.7.6. The Change Attribute and File System Transitions . . 232 | 11.7.6. The Change Attribute and File System Transitions . . 233 | |||
11.7.7. Lock State and File System Transitions . . . . . . . 233 | 11.7.7. Lock State and File System Transitions . . . . . . . 234 | |||
11.7.8. Write Verifiers and File System Transitions . . . . 237 | 11.7.8. Write Verifiers and File System Transitions . . . . 238 | |||
11.7.9. Readdir Cookies and Verifiers and File System | 11.7.9. Readdir Cookies and Verifiers and File System | |||
Transitions . . . . . . . . . . . . . . . . . . . . 237 | Transitions . . . . . . . . . . . . . . . . . . . . 238 | |||
11.7.10. File System Data and File System Transitions . . . . 237 | 11.7.10. File System Data and File System Transitions . . . . 238 | |||
11.8. Effecting File System Referrals . . . . . . . . . . . . 239 | 11.8. Effecting File System Referrals . . . . . . . . . . . . 240 | |||
11.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 239 | 11.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 240 | |||
11.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 243 | 11.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 244 | |||
11.9. The Attribute fs_locations . . . . . . . . . . . . . . . 245 | 11.9. The Attribute fs_locations . . . . . . . . . . . . . . . 246 | |||
11.10. The Attribute fs_locations_info . . . . . . . . . . . . 248 | 11.10. The Attribute fs_locations_info . . . . . . . . . . . . 249 | |||
11.10.1. The fs_locations_server4 Structure . . . . . . . . . 252 | 11.10.1. The fs_locations_server4 Structure . . . . . . . . . 253 | |||
11.10.2. The fs_locations_info4 Structure . . . . . . . . . . 257 | 11.10.2. The fs_locations_info4 Structure . . . . . . . . . . 258 | |||
11.10.3. The fs_locations_item4 Structure . . . . . . . . . . 258 | 11.10.3. The fs_locations_item4 Structure . . . . . . . . . . 259 | |||
11.11. The Attribute fs_status . . . . . . . . . . . . . . . . 260 | 11.11. The Attribute fs_status . . . . . . . . . . . . . . . . 261 | |||
12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 264 | 12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 265 | |||
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 264 | 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 265 | |||
12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 265 | 12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 266 | |||
12.2.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 266 | 12.2.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 267 | |||
12.2.2. Metadata Server . . . . . . . . . . . . . . . . . . 266 | 12.2.2. Metadata Server . . . . . . . . . . . . . . . . . . 267 | |||
12.2.3. pNFS Client . . . . . . . . . . . . . . . . . . . . 266 | 12.2.3. pNFS Client . . . . . . . . . . . . . . . . . . . . 267 | |||
12.2.4. Storage Device . . . . . . . . . . . . . . . . . . . 266 | 12.2.4. Storage Device . . . . . . . . . . . . . . . . . . . 267 | |||
12.2.5. Storage Protocol . . . . . . . . . . . . . . . . . . 266 | 12.2.5. Storage Protocol . . . . . . . . . . . . . . . . . . 267 | |||
12.2.6. Control Protocol . . . . . . . . . . . . . . . . . . 267 | 12.2.6. Control Protocol . . . . . . . . . . . . . . . . . . 268 | |||
12.2.7. Layout Types . . . . . . . . . . . . . . . . . . . . 267 | 12.2.7. Layout Types . . . . . . . . . . . . . . . . . . . . 268 | |||
12.2.8. Layout . . . . . . . . . . . . . . . . . . . . . . . 268 | 12.2.8. Layout . . . . . . . . . . . . . . . . . . . . . . . 269 | |||
12.2.9. Layout Iomode . . . . . . . . . . . . . . . . . . . 268 | 12.2.9. Layout Iomode . . . . . . . . . . . . . . . . . . . 269 | |||
12.2.10. Device IDs . . . . . . . . . . . . . . . . . . . . . 269 | 12.2.10. Device IDs . . . . . . . . . . . . . . . . . . . . . 270 | |||
12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 270 | 12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 271 | |||
12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 271 | 12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 272 | |||
12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 271 | 12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 272 | |||
12.5.1. Guarantees Provided by Layouts . . . . . . . . . . . 271 | 12.5.1. Guarantees Provided by Layouts . . . . . . . . . . . 272 | |||
12.5.2. Getting a Layout . . . . . . . . . . . . . . . . . . 272 | 12.5.2. Getting a Layout . . . . . . . . . . . . . . . . . . 273 | |||
12.5.3. Layout Stateid . . . . . . . . . . . . . . . . . . . 273 | 12.5.3. Layout Stateid . . . . . . . . . . . . . . . . . . . 274 | |||
12.5.4. Committing a Layout . . . . . . . . . . . . . . . . 274 | 12.5.4. Committing a Layout . . . . . . . . . . . . . . . . 275 | |||
12.5.5. Recalling a Layout . . . . . . . . . . . . . . . . . 278 | 12.5.5. Recalling a Layout . . . . . . . . . . . . . . . . . 279 | |||
12.5.6. Revoking Layouts . . . . . . . . . . . . . . . . . . 285 | 12.5.6. Revoking Layouts . . . . . . . . . . . . . . . . . . 286 | |||
12.5.7. Metadata Server Write Propagation . . . . . . . . . 285 | 12.5.7. Metadata Server Write Propagation . . . . . . . . . 286 | |||
12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 286 | 12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 287 | |||
12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 287 | 12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 288 | |||
12.7.1. Recovery from Client Restart . . . . . . . . . . . . 287 | 12.7.1. Recovery from Client Restart . . . . . . . . . . . . 288 | |||
12.7.2. Dealing with Lease Expiration on the Client . . . . 288 | 12.7.2. Dealing with Lease Expiration on the Client . . . . 289 | |||
12.7.3. Dealing with Loss of Layout State on the Metadata | 12.7.3. Dealing with Loss of Layout State on the Metadata | |||
Server . . . . . . . . . . . . . . . . . . . . . . . 289 | Server . . . . . . . . . . . . . . . . . . . . . . . 290 | |||
12.7.4. Recovery from Metadata Server Restart . . . . . . . 289 | 12.7.4. Recovery from Metadata Server Restart . . . . . . . 290 | |||
12.7.5. Operations During Metadata Server Grace Period . . . 291 | 12.7.5. Operations During Metadata Server Grace Period . . . 292 | |||
12.7.6. Storage Device Recovery . . . . . . . . . . . . . . 292 | 12.7.6. Storage Device Recovery . . . . . . . . . . . . . . 293 | |||
12.8. Metadata and Storage Device Roles . . . . . . . . . . . 292 | 12.8. Metadata and Storage Device Roles . . . . . . . . . . . 293 | |||
12.9. Security Considerations for pNFS . . . . . . . . . . . . 293 | 12.9. Security Considerations for pNFS . . . . . . . . . . . . 294 | |||
13. PNFS: NFSv4.1 File Layout Type . . . . . . . . . . . . . . . 294 | 13. PNFS: NFSv4.1 File Layout Type . . . . . . . . . . . . . . . 295 | |||
13.1. Client ID and Session Considerations . . . . . . . . . . 294 | 13.1. Client ID and Session Considerations . . . . . . . . . . 295 | |||
13.1.1. Sessions Considerations for Data Servers . . . . . . 296 | 13.1.1. Sessions Considerations for Data Servers . . . . . . 297 | |||
13.2. File Layout Definitions . . . . . . . . . . . . . . . . 297 | 13.2. File Layout Definitions . . . . . . . . . . . . . . . . 298 | |||
13.3. File Layout Data Types . . . . . . . . . . . . . . . . . 297 | 13.3. File Layout Data Types . . . . . . . . . . . . . . . . . 298 | |||
13.4. Interpreting the File Layout . . . . . . . . . . . . . . 301 | 13.4. Interpreting the File Layout . . . . . . . . . . . . . . 302 | |||
13.4.1. Determining the Stripe Unit Number . . . . . . . . . 301 | 13.4.1. Determining the Stripe Unit Number . . . . . . . . . 302 | |||
13.4.2. Interpreting the File Layout Using Sparse Packing . 301 | 13.4.2. Interpreting the File Layout Using Sparse Packing . 302 | |||
13.4.3. Interpreting the File Layout Using Dense Packing . . 304 | 13.4.3. Interpreting the File Layout Using Dense Packing . . 305 | |||
13.4.4. Sparse and Dense Stripe Unit Packing . . . . . . . . 306 | 13.4.4. Sparse and Dense Stripe Unit Packing . . . . . . . . 307 | |||
13.5. Data Server Multipathing . . . . . . . . . . . . . . . . 308 | 13.5. Data Server Multipathing . . . . . . . . . . . . . . . . 309 | |||
13.6. Operations Sent to NFSv4.1 Data Servers . . . . . . . . 309 | 13.6. Operations Sent to NFSv4.1 Data Servers . . . . . . . . 310 | |||
13.7. COMMIT Through Metadata Server . . . . . . . . . . . . . 311 | 13.7. COMMIT Through Metadata Server . . . . . . . . . . . . . 312 | |||
13.8. The Layout Iomode . . . . . . . . . . . . . . . . . . . 313 | 13.8. The Layout Iomode . . . . . . . . . . . . . . . . . . . 314 | |||
13.9. Metadata and Data Server State Coordination . . . . . . 313 | 13.9. Metadata and Data Server State Coordination . . . . . . 314 | |||
13.9.1. Global Stateid Requirements . . . . . . . . . . . . 313 | 13.9.1. Global Stateid Requirements . . . . . . . . . . . . 314 | |||
13.9.2. Data Server State Propagation . . . . . . . . . . . 314 | 13.9.2. Data Server State Propagation . . . . . . . . . . . 315 | |||
13.10. Data Server Component File Size . . . . . . . . . . . . 316 | 13.10. Data Server Component File Size . . . . . . . . . . . . 317 | |||
13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 317 | 13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 318 | |||
13.12. Security Considerations for the File Layout Type . . . . 317 | 13.12. Security Considerations for the File Layout Type . . . . 318 | |||
14. Internationalization . . . . . . . . . . . . . . . . . . . . 318 | 14. Internationalization . . . . . . . . . . . . . . . . . . . . 319 | |||
14.1. Stringprep profile for the utf8str_cs type . . . . . . . 319 | 14.1. Stringprep profile for the utf8str_cs type . . . . . . . 320 | |||
14.2. Stringprep profile for the utf8str_cis type . . . . . . 321 | 14.2. Stringprep profile for the utf8str_cis type . . . . . . 322 | |||
14.3. Stringprep profile for the utf8str_mixed type . . . . . 322 | 14.3. Stringprep profile for the utf8str_mixed type . . . . . 323 | |||
14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 324 | 14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 325 | |||
14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 324 | 14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 325 | |||
15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 325 | 15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 326 | |||
15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 325 | 15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 326 | |||
15.1.1. General Errors . . . . . . . . . . . . . . . . . . . 327 | 15.1.1. General Errors . . . . . . . . . . . . . . . . . . . 328 | |||
15.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 329 | 15.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 330 | |||
15.1.3. Compound Structure Errors . . . . . . . . . . . . . 330 | 15.1.3. Compound Structure Errors . . . . . . . . . . . . . 331 | |||
15.1.4. File System Errors . . . . . . . . . . . . . . . . . 332 | 15.1.4. File System Errors . . . . . . . . . . . . . . . . . 333 | |||
15.1.5. State Management Errors . . . . . . . . . . . . . . 334 | 15.1.5. State Management Errors . . . . . . . . . . . . . . 335 | |||
15.1.6. Security Errors . . . . . . . . . . . . . . . . . . 335 | 15.1.6. Security Errors . . . . . . . . . . . . . . . . . . 336 | |||
15.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 335 | 15.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 336 | |||
15.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 336 | 15.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 337 | |||
15.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 337 | 15.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 338 | |||
15.1.10. pNFS Errors . . . . . . . . . . . . . . . . . . . . 338 | 15.1.10. pNFS Errors . . . . . . . . . . . . . . . . . . . . 339 | |||
15.1.11. Session Use Errors . . . . . . . . . . . . . . . . . 339 | 15.1.11. Session Use Errors . . . . . . . . . . . . . . . . . 340 | |||
15.1.12. Session Management Errors . . . . . . . . . . . . . 341 | 15.1.12. Session Management Errors . . . . . . . . . . . . . 342 | |||
15.1.13. Client Management Errors . . . . . . . . . . . . . . 341 | 15.1.13. Client Management Errors . . . . . . . . . . . . . . 342 | |||
15.1.14. Delegation Errors . . . . . . . . . . . . . . . . . 342 | 15.1.14. Delegation Errors . . . . . . . . . . . . . . . . . 343 | |||
15.1.15. Attribute Handling Errors . . . . . . . . . . . . . 342 | 15.1.15. Attribute Handling Errors . . . . . . . . . . . . . 343 | |||
15.1.16. Obsoleted Errors . . . . . . . . . . . . . . . . . . 343 | 15.1.16. Obsoleted Errors . . . . . . . . . . . . . . . . . . 344 | |||
15.2. Operations and their valid errors . . . . . . . . . . . 344 | 15.2. Operations and their valid errors . . . . . . . . . . . 345 | |||
15.3. Callback operations and their valid errors . . . . . . . 360 | 15.3. Callback operations and their valid errors . . . . . . . 361 | |||
15.4. Errors and the operations that use them . . . . . . . . 362 | 15.4. Errors and the operations that use them . . . . . . . . 363 | |||
16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 376 | 16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 377 | |||
16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 376 | 16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 377 | |||
16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 377 | 16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 378 | |||
17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 388 | 17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 389 | |||
18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 391 | 18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 392 | |||
18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 391 | 18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 392 | |||
18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 397 | 18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 398 | |||
18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 398 | 18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 399 | |||
18.4. Operation 6: CREATE - Create a Non-Regular File Object . 401 | 18.4. Operation 6: CREATE - Create a Non-Regular File Object . 402 | |||
18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting | 18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting | |||
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 404 | Recovery . . . . . . . . . . . . . . . . . . . . . . . . 405 | |||
18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 405 | 18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 406 | |||
18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 405 | 18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 406 | |||
18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 407 | 18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 408 | |||
18.9. Operation 11: LINK - Create Link to a File . . . . . . . 408 | 18.9. Operation 11: LINK - Create Link to a File . . . . . . . 409 | |||
18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 411 | 18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 412 | |||
18.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 415 | 18.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 416 | |||
18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 416 | 18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 417 | |||
18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 418 | 18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 419 | |||
18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 419 | 18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 420 | |||
18.15. Operation 17: NVERIFY - Verify Difference in | 18.15. Operation 17: NVERIFY - Verify Difference in | |||
Attributes . . . . . . . . . . . . . . . . . . . . . . . 421 | Attributes . . . . . . . . . . . . . . . . . . . . . . . 422 | |||
18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 422 | 18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 423 | |||
18.17. Operation 19: OPENATTR - Open Named Attribute | 18.17. Operation 19: OPENATTR - Open Named Attribute | |||
Directory . . . . . . . . . . . . . . . . . . . . . . . 441 | Directory . . . . . . . . . . . . . . . . . . . . . . . 442 | |||
18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 442 | 18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 443 | |||
18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 444 | 18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 445 | |||
18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 444 | 18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 445 | |||
18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 446 | 18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 447 | |||
18.22. Operation 25: READ - Read from File . . . . . . . . . . 447 | 18.22. Operation 25: READ - Read from File . . . . . . . . . . 448 | |||
18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 449 | 18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 450 | |||
18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 453 | 18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 454 | |||
18.25. Operation 28: REMOVE - Remove File System Object . . . . 454 | 18.25. Operation 28: REMOVE - Remove File System Object . . . . 455 | |||
18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 456 | 18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 457 | |||
18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 460 | 18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 461 | |||
18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 461 | 18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 462 | |||
18.29. Operation 33: SECINFO - Obtain Available Security . . . 462 | 18.29. Operation 33: SECINFO - Obtain Available Security . . . 463 | |||
18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 465 | 18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 467 | |||
18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 468 | 18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 470 | |||
18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 469 | 18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 471 | |||
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control . . 474 | 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control . . 475 | |||
18.34. Operation 41: BIND_CONN_TO_SESSION . . . . . . . . . . . 475 | 18.34. Operation 41: BIND_CONN_TO_SESSION . . . . . . . . . . . 477 | |||
18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 478 | 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 479 | |||
18.36. Operation 43: CREATE_SESSION - Create New Session and | 18.36. Operation 43: CREATE_SESSION - Create New Session and | |||
Confirm Client ID . . . . . . . . . . . . . . . . . . . 494 | Confirm Client ID . . . . . . . . . . . . . . . . . . . 495 | |||
18.37. Operation 44: DESTROY_SESSION - Destroy existing | 18.37. Operation 44: DESTROY_SESSION - Destroy existing | |||
session . . . . . . . . . . . . . . . . . . . . . . . . 504 | session . . . . . . . . . . . . . . . . . . . . . . . . 505 | |||
18.38. Operation 45: FREE_STATEID - Free stateid with no | 18.38. Operation 45: FREE_STATEID - Free stateid with no | |||
locks . . . . . . . . . . . . . . . . . . . . . . . . . 506 | locks . . . . . . . . . . . . . . . . . . . . . . . . . 507 | |||
18.39. Operation 46: GET_DIR_DELEGATION - Get a directory | 18.39. Operation 46: GET_DIR_DELEGATION - Get a directory | |||
delegation . . . . . . . . . . . . . . . . . . . . . . . 507 | delegation . . . . . . . . . . . . . . . . . . . . . . . 508 | |||
18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 511 | 18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 512 | |||
18.41. Operation 48: GETDEVICELIST - Get All Device Mappings | 18.41. Operation 48: GETDEVICELIST - Get All Device Mappings | |||
for a File System . . . . . . . . . . . . . . . . . . . 513 | for a File System . . . . . . . . . . . . . . . . . . . 514 | |||
18.42. Operation 49: LAYOUTCOMMIT - Commit writes made using | 18.42. Operation 49: LAYOUTCOMMIT - Commit writes made using | |||
a layout . . . . . . . . . . . . . . . . . . . . . . . . 515 | a layout . . . . . . . . . . . . . . . . . . . . . . . . 516 | |||
18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 518 | 18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 519 | |||
18.44. Operation 51: LAYOUTRETURN - Release Layout | 18.44. Operation 51: LAYOUTRETURN - Release Layout | |||
Information . . . . . . . . . . . . . . . . . . . . . . 522 | Information . . . . . . . . . . . . . . . . . . . . . . 523 | |||
18.45. Operation 52: SECINFO_NO_NAME - Get Security on | 18.45. Operation 52: SECINFO_NO_NAME - Get Security on | |||
Unnamed Object . . . . . . . . . . . . . . . . . . . . . 527 | Unnamed Object . . . . . . . . . . . . . . . . . . . . . 528 | |||
18.46. Operation 53: SEQUENCE - Supply per-procedure | 18.46. Operation 53: SEQUENCE - Supply per-procedure | |||
sequencing and control . . . . . . . . . . . . . . . . . 528 | sequencing and control . . . . . . . . . . . . . . . . . 529 | |||
18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 534 | 18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 535 | |||
18.48. Operation 55: TEST_STATEID - Test stateids for | 18.48. Operation 55: TEST_STATEID - Test stateids for | |||
validity . . . . . . . . . . . . . . . . . . . . . . . . 536 | validity . . . . . . . . . . . . . . . . . . . . . . . . 537 | |||
18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 538 | 18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 539 | |||
18.50. Operation 57: DESTROY_CLIENTID - Destroy existing | 18.50. Operation 57: DESTROY_CLIENTID - Destroy existing | |||
client ID . . . . . . . . . . . . . . . . . . . . . . . 542 | client ID . . . . . . . . . . . . . . . . . . . . . . . 542 | |||
18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims | 18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims | |||
Finished . . . . . . . . . . . . . . . . . . . . . . . . 542 | Finished . . . . . . . . . . . . . . . . . . . . . . . . 542 | |||
18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 545 | 18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 545 | |||
19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 545 | 19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 545 | |||
19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 546 | 19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 546 | |||
19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 546 | 19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 546 | |||
20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 550 | 20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 550 | |||
20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 550 | 20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 550 | |||
skipping to change at page 30, line 49 | skipping to change at page 30, line 49 | |||
communication with the server, the client may receive an NFS error of | communication with the server, the client may receive an NFS error of | |||
NFS4ERR_WRONGSEC. This error allows the server to notify the client | NFS4ERR_WRONGSEC. This error allows the server to notify the client | |||
that the security tuple currently being used contravenes the server's | that the security tuple currently being used contravenes the server's | |||
security policy. The client is then responsible for determining (see | security policy. The client is then responsible for determining (see | |||
Section 2.6.3.1) what security tuples are available at the server and | Section 2.6.3.1) what security tuples are available at the server and | |||
choosing one which is appropriate for the client. | choosing one which is appropriate for the client. | |||
2.6.3.1. Using NFS4ERR_WRONGSEC, SECINFO, and SECINFO_NO_NAME | 2.6.3.1. Using NFS4ERR_WRONGSEC, SECINFO, and SECINFO_NO_NAME | |||
This section explains of the mechanics of NFSv4.1 security | This section explains of the mechanics of NFSv4.1 security | |||
negotiation. The term "put filehandle operation" refers to | negotiation. | |||
PUTROOTFH, PUTPUBFH, PUTFH, and RESTOREFH. | ||||
2.6.3.1.1. Put Filehandle Operation + SAVEFH | 2.6.3.1.1. Put Filehandle Operations | |||
The client is saving a filehandle for a future RESTOREFH. The server | The term "put filehandle operation" refers to PUTROOTFH, PUTPUBFH, | |||
MUST NOT return NFS4ERR_WRONGSEC to either the put filehandle | PUTFH, and RESTOREFH. Each of the subsections herein describes how | |||
operation or SAVEFH. | the server handles a subseries of operations that starts with a put | |||
filehandle operation. | ||||
2.6.3.1.2. Two or More Put Filehandle Operations | 2.6.3.1.1.1. Put Filehandle Operation + SAVEFH | |||
The client is saving a filehandle for a future RESTOREFH, LINK, or | ||||
RENAME. SAVEFH MUST NOT return NFS4ERR_WRONGSEC. To determine | ||||
whether the put filehandle operation returns NFS4ERR_WRONGSEC or not, | ||||
the server implementation pretends SAVEFH is not in the series of | ||||
operations and examines which of the situations described in the | ||||
other subsections of Section 2.6.3.1.1 apply. | ||||
2.6.3.1.1.2. Two or More Put Filehandle Operations | ||||
For a series of N put filehandle operations, the server MUST NOT | For a series of N put filehandle operations, the server MUST NOT | |||
return NFS4ERR_WRONGSEC to the first N-1 put filehandle operations. | return NFS4ERR_WRONGSEC to the first N-1 put filehandle operations. | |||
The N'th put filehandle operation is handled as if it is the first in | The N'th put filehandle operation is handled as if it is the first in | |||
a subseries of operations. For example if the server received PUTFH, | a subseries of operations. For example if the server received PUTFH, | |||
PUTROOTFH, LOOKUP, then the PUTFH is ignored for NFS4ERR_WRONGSEC | PUTROOTFH, LOOKUP, then the PUTFH is ignored for NFS4ERR_WRONGSEC | |||
purposes, and the PUTROOTFH, LOOKUP subseries is processed as | purposes, and the PUTROOTFH, LOOKUP subseries is processed as | |||
according to Section 2.6.3.1.3. | according to Section 2.6.3.1.1.3. | |||
2.6.3.1.3. Put Filehandle Operation + LOOKUP (or OPEN by Name) | 2.6.3.1.1.3. Put Filehandle Operation + LOOKUP (or OPEN of an Existing | |||
Name) | ||||
This situation also applies to a put filehandle operation followed by | This situation also applies to a put filehandle operation followed by | |||
a LOOKUP or an OPEN operation that specifies a component name. | a LOOKUP or an OPEN operation that specifies an existing component | |||
name. | ||||
In this situation, the client is potentially crossing a security | In this situation, the client is potentially crossing a security | |||
policy boundary, and the set of security tuples the parent directory | policy boundary, and the set of security tuples the parent directory | |||
supports may differ from those of the child. The server | supports may differ from those of the child. The server | |||
implementation may decide whether to impose any restrictions on | implementation may decide whether to impose any restrictions on | |||
security policy administration. There are at least three approaches | security policy administration. There are at least three approaches | |||
(sec_policy_child is the tuple set of the child export, | (sec_policy_child is the tuple set of the child export, | |||
sec_policy_parent is that of the parent). | sec_policy_parent is that of the parent). | |||
a) sec_policy_child <= sec_policy_parent (<= for subset). This | a) sec_policy_child <= sec_policy_parent (<= for subset). This | |||
skipping to change at page 31, line 50 | skipping to change at page 32, line 16 | |||
{} for the empty set). This means that the security tuples | {} for the empty set). This means that the security tuples | |||
specified on the security policy of a child directory always has a | specified on the security policy of a child directory always has a | |||
non empty intersection with that of the parent. | non empty intersection with that of the parent. | |||
c) sec_policy_child ^ sec_policy_parent == {}. This means that | c) sec_policy_child ^ sec_policy_parent == {}. This means that | |||
the set of tuples specified on the security policy of a child | the set of tuples specified on the security policy of a child | |||
directory may not intersect with that of the parent. In other | directory may not intersect with that of the parent. In other | |||
words, there are no restrictions on how the system administrator | words, there are no restrictions on how the system administrator | |||
may set up these tuples. | may set up these tuples. | |||
For a server to support approach (b) (when client chooses a flavor | In order for a server to support approaches (b) (for the case when a | |||
that is not a member of sec_policy_parent) and (c), the put | client chooses a flavor that is not a member of sec_policy_parent) | |||
filehandle operation must NOT return NFS4ERR_WRONGSEC when there is a | and (c), the put filehandle operation cannot return NFS4ERR_WRONGSEC | |||
security tuple mismatch. Instead, it should be returned from the | when there is a security tuple mismatch. Instead, it should be | |||
LOOKUP (or OPEN by component name) that follows. | returned from the LOOKUP (or OPEN by existing component name) that | |||
follows. | ||||
Since the above guideline does not contradict approach (a), it should | Since the above guideline does not contradict approach (a), it should | |||
be followed in general. Even if approach (a) is implemented, it is | be followed in general. Even if approach (a) is implemented, it is | |||
possible for the security tuple used to be acceptable for the target | possible for the security tuple used to be acceptable for the target | |||
of LOOKUP but not for the filehandles used in the put filehandle | of LOOKUP but not for the filehandles used in the put filehandle | |||
operation. The put filehandle operation could be a PUTROOTFH or | operation. The put filehandle operation could be a PUTROOTFH or | |||
PUTPUBFH, where the client cannot know the security tuples for the | PUTPUBFH, where the client cannot know the security tuples for the | |||
root or public filehandle. Or the security policy for the filehandle | root or public filehandle. Or the security policy for the filehandle | |||
used by the put filehandle operation could have changed since the | used by the put filehandle operation could have changed since the | |||
time the filehandle was obtained. | time the filehandle was obtained. | |||
Therefore, an NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC in | Therefore, an NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC in | |||
response to the put filehandle operation if the operation is | response to the put filehandle operation if the operation is | |||
immediately followed by a LOOKUP or an OPEN by component name. | immediately followed by a LOOKUP or an OPEN by component name. | |||
2.6.3.1.4. Put Filehandle Operation + LOOKUPP | 2.6.3.1.1.4. Put Filehandle Operation + LOOKUPP | |||
Since SECINFO only works its way down, there is no way LOOKUPP can | Since SECINFO only works its way down, there is no way LOOKUPP can | |||
return NFS4ERR_WRONGSEC without SECINFO_NO_NAME. SECINFO_NO_NAME | return NFS4ERR_WRONGSEC without SECINFO_NO_NAME. SECINFO_NO_NAME | |||
solves this issue via style SECINFO_STYLE4_PARENT, which works in the | solves this issue via style SECINFO_STYLE4_PARENT, which works in the | |||
opposite direction as SECINFO. As with Section 2.6.3.1.3, a put | opposite direction as SECINFO. As with Section 2.6.3.1.1.3, a put | |||
filehandle operation that is followed by a LOOKUPP MUST NOT return | filehandle operation that is followed by a LOOKUPP MUST NOT return | |||
NFS4ERR_WRONGSEC. If the server does not support SECINFO_NO_NAME, | NFS4ERR_WRONGSEC. If the server does not support SECINFO_NO_NAME, | |||
the client's only recourse is to send the put filehandle operation, | the client's only recourse is to send the put filehandle operation, | |||
LOOKUPP, GETFH sequence of operations with every security tuple it | LOOKUPP, GETFH sequence of operations with every security tuple it | |||
supports. | supports. | |||
Regardless of whether SECINFO_NO_NAME is supported, an NFSv4.1 server | Regardless of whether SECINFO_NO_NAME is supported, an NFSv4.1 server | |||
MUST NOT return NFS4ERR_WRONGSEC in response to a put filehandle | MUST NOT return NFS4ERR_WRONGSEC in response to a put filehandle | |||
operation if the operation is immediately followed by a LOOKUPP. | operation if the operation is immediately followed by a LOOKUPP. | |||
2.6.3.1.5. Put Filehandle Operation + SECINFO/SECINFO_NO_NAME | 2.6.3.1.1.5. Put Filehandle Operation + SECINFO/SECINFO_NO_NAME | |||
A security sensitive client is allowed to choose a strong security | A security sensitive client is allowed to choose a strong security | |||
tuple when querying a server to determine a file object's permitted | tuple when querying a server to determine a file object's permitted | |||
security tuples. The security tuple chosen by the client does not | security tuples. The security tuple chosen by the client does not | |||
have to be included in the tuple list of the security policy of the | have to be included in the tuple list of the security policy of the | |||
either parent directory indicated in the put filehandle operation, or | either parent directory indicated in the put filehandle operation, or | |||
the child file object indicated in SECINFO (or any parent directory | the child file object indicated in SECINFO (or any parent directory | |||
indicated in SECINFO_NO_NAME). Of course the server has to be | indicated in SECINFO_NO_NAME). Of course the server has to be | |||
configured for whatever security tuple the client selects, otherwise | configured for whatever security tuple the client selects, otherwise | |||
the request will fail at RPC layer with an appropriate authentication | the request will fail at RPC layer with an appropriate authentication | |||
skipping to change at page 33, line 13 | skipping to change at page 33, line 29 | |||
SECINFO or SECINFO_NO_NAME and those supported by the security | SECINFO or SECINFO_NO_NAME and those supported by the security | |||
policy. But in practice, the client may start looking for strong | policy. But in practice, the client may start looking for strong | |||
flavors from those supported by the security policy, followed by | flavors from those supported by the security policy, followed by | |||
those in the REQUIRED set. | those in the REQUIRED set. | |||
The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to a put | The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to a put | |||
filehandle operation that is immediately followed by SECINFO or | filehandle operation that is immediately followed by SECINFO or | |||
SECINFO_NO_NAME. The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC | SECINFO_NO_NAME. The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC | |||
from SECINFO or SECINFO_NO_NAME. | from SECINFO or SECINFO_NO_NAME. | |||
2.6.3.1.6. Put Filehandle Operation + Nothing | 2.6.3.1.1.6. Put Filehandle Operation + Nothing | |||
The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC. | The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC. | |||
2.6.3.1.7. Put Filehandle Operation + Anything Else | 2.6.3.1.1.7. Put Filehandle Operation + Anything Else | |||
"Anything Else" includes OPEN by filehandle. | "Anything Else" includes OPEN by filehandle. | |||
The security policy enforcement applies to the filehandle specified | The security policy enforcement applies to the filehandle specified | |||
in the put filehandle operation. Therefore the put filehandle | in the put filehandle operation. Therefore the put filehandle | |||
operation must return NFS4ERR_WRONGSEC when there is a security tuple | operation must return NFS4ERR_WRONGSEC when there is a security tuple | |||
mismatch. This avoids the complexity adding NFS4ERR_WRONGSEC as an | mismatch. This avoids the complexity adding NFS4ERR_WRONGSEC as an | |||
allowable error to every other operation. | allowable error to every other operation. | |||
A COMPOUND containing the series put filehandle operation + | A COMPOUND containing the series put filehandle operation + | |||
SECINFO_NO_NAME (style SECINFO_STYLE4_CURRENT_FH) is an efficient way | SECINFO_NO_NAME (style SECINFO_STYLE4_CURRENT_FH) is an efficient way | |||
for the client to recover from NFS4ERR_WRONGSEC. | for the client to recover from NFS4ERR_WRONGSEC. | |||
The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to any operation | The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to any operation | |||
other than a put filehandle operation, LOOKUP, LOOKUPP, and OPEN (by | other than a put filehandle operation, LOOKUP, LOOKUPP, and OPEN (by | |||
component name). | component name). | |||
2.6.3.1.8. Operations after SECINFO and SECINFO_NO_NAME | 2.6.3.1.1.8. Operations after SECINFO and SECINFO_NO_NAME | |||
Suppose a client sends a COMPOUND procedure containing the series | Suppose a client sends a COMPOUND procedure containing the series | |||
SEQUENCE, PUTFH, SECINFO_NONAME, READ, and suppose the security tuple | SEQUENCE, PUTFH, SECINFO_NONAME, READ, and suppose the security tuple | |||
used does not match that required for the target file. By rule (see | used does not match that required for the target file. By rule (see | |||
Section 2.6.3.1.5), neither PUTFH nor SECINFO_NO_NAME can return | Section 2.6.3.1.1.5), neither PUTFH nor SECINFO_NO_NAME can return | |||
NFS4ERR_WRONGSEC. By rule (see Section 2.6.3.1.7), READ cannot | NFS4ERR_WRONGSEC. By rule (see Section 2.6.3.1.1.7), READ cannot | |||
return NFS4ERR_WRONGSEC. The issue is resolved by the fact that | return NFS4ERR_WRONGSEC. The issue is resolved by the fact that | |||
SECINFO and SECINFO_NO_NAME consume the current filehandle (note that | SECINFO and SECINFO_NO_NAME consume the current filehandle (note that | |||
this is a change from NFSv4.0). This leaves no current filehandle | this is a change from NFSv4.0). This leaves no current filehandle | |||
for READ to use, and READ returns NFS4ERR_NOFILEHANDLE. | for READ to use, and READ returns NFS4ERR_NOFILEHANDLE. | |||
2.6.3.1.2. LINK and RENAME | ||||
The LINK and RENAME operations use both the current and saved | ||||
filehandles. When the current filehandle is injected into a series | ||||
of operations via a put filehandle operation, the server MUST return | ||||
NFS4ERR_WRONGSEC, per Section 2.6.3.1.1. LINK and RENAME MAY return | ||||
NFS4ERR_WRONGSEC if the security policy of the saved filehandle | ||||
rejects the security flavor used in the COMPOUND request's | ||||
credentials. If the server does so, then if there is no intersection | ||||
between the security policies of saved and current filehandles, this | ||||
means it will be impossible for client to perform the intended LINK | ||||
or RENAME operation. | ||||
For example, suppose the client sends this COMPOUND request: | ||||
SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, RENAME "c" "d", where | ||||
filehandles bFH and aFH refer to different directories. Suppose no | ||||
common security tuple exists between the security policies of aFH and | ||||
bFH. If the client sends the request using credentials acceptable to | ||||
bFH's security policy but not aFH's policy, then the PUTFH aFH | ||||
operation will fail with NFS4ERR_WRONGSEC. After a SECINFO_NO_NAME | ||||
request, the client sends SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, | ||||
RENAME "c" "d", using credentials acceptable to aFH's security | ||||
policy, but not bFH's policy. The server returns NFS4ERR_WRONGSEC on | ||||
the RENAME operation. | ||||
To prevent a client from an endless sequence of a request containing | ||||
LINK or RENAME, followed by a request containing SECINFO_NO_NAME, the | ||||
server MUST detect when the security policies of the current and | ||||
saved filehandles have no mutually acceptable security tuple, and | ||||
MUST NOT NFS4ERR_WRONGSEC in that situation. Instead the server MUST | ||||
return NFS4ERR_XDEV. | ||||
Thus while a server MAY return NFS4ERR_WRONGSEC from LINK and RENAME, | ||||
the server implementor may reasonably decide the consequences are not | ||||
worth the security benefits, and so allow the security policy of the | ||||
current filehandle to override that of the saved filehandle. | ||||
2.7. Minor Versioning | 2.7. Minor Versioning | |||
To address the requirement of an NFS protocol that can evolve as the | To address the requirement of an NFS protocol that can evolve as the | |||
need arises, the NFSv4.1 protocol contains the rules and framework to | need arises, the NFSv4.1 protocol contains the rules and framework to | |||
allow for future minor changes or versioning. | allow for future minor changes or versioning. | |||
The base assumption with respect to minor versioning is that any | The base assumption with respect to minor versioning is that any | |||
future accepted minor version must follow the IETF process and be | future accepted minor version must follow the IETF process and be | |||
documented in a standards track RFC. Therefore, each minor version | documented in a standards track RFC. Therefore, each minor version | |||
number will correspond to an RFC. Minor version zero of the NFSv4 | number will correspond to an RFC. Minor version zero of the NFSv4 | |||
skipping to change at page 100, line 8 | skipping to change at page 101, line 8 | |||
hte columns of the table are: | hte columns of the table are: | |||
o Name: the name of attribute | o Name: the name of attribute | |||
o Id: the number assigned to the attribute. In the event of | o Id: the number assigned to the attribute. In the event of | |||
conflicts between the assigned number and [12], the latter is | conflicts between the assigned number and [12], the latter is | |||
authoritative. | authoritative. | |||
o Data Type: The XDR data type of the attribute. | o Data Type: The XDR data type of the attribute. | |||
o Acc: Access allowed. RD means read-only (GETATTR may retrieve, | o Acc: Access allowed to the attribute. R means read-only (GETATTR | |||
SETATTR may not set). WR means write-only (SETATTR may set, | may retrieve, SETATTR may not set). W means write-only (SETATTR | |||
GETATTR may not retrieve). R/W means SETATTR may set, and GETATTR | may set, GETATTR may not retrieve). R W means read/write (GETATTR | |||
may retrieve the attribute. | may retrieve, SETATTR may set). | |||
o Defined in: the section of this specification that describes the | o 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: | | |||
+--------------------+----+------------+-----+------------------+ | +--------------------+----+------------+-----+------------------+ | |||
| supported_attrs | 0 | bitmap4 | RD | Section 5.8.1.1 | | | supported_attrs | 0 | bitmap4 | R | Section 5.8.1.1 | | |||
| type | 1 | nfs_ftype4 | RD | Section 5.8.1.2 | | | type | 1 | nfs_ftype4 | R | Section 5.8.1.2 | | |||
| fh_expire_type | 2 | uint32_t | RD | Section 5.8.1.3 | | | fh_expire_type | 2 | uint32_t | R | Section 5.8.1.3 | | |||
| change | 3 | uint64_t | RD | Section 5.8.1.4 | | | change | 3 | uint64_t | R | Section 5.8.1.4 | | |||
| size | 4 | uint64_t | R/W | Section 5.8.1.5 | | | size | 4 | uint64_t | R W | Section 5.8.1.5 | | |||
| link_support | 5 | bool | RD | Section 5.8.1.6 | | | link_support | 5 | bool | R | Section 5.8.1.6 | | |||
| symlink_support | 6 | bool | RD | Section 5.8.1.7 | | | symlink_support | 6 | bool | R | Section 5.8.1.7 | | |||
| named_attr | 7 | bool | RD | Section 5.8.1.8 | | | named_attr | 7 | bool | R | Section 5.8.1.8 | | |||
| fsid | 8 | fsid4 | RD | Section 5.8.1.9 | | | fsid | 8 | fsid4 | R | Section 5.8.1.9 | | |||
| unique_handles | 9 | bool | RD | Section 5.8.1.10 | | | unique_handles | 9 | bool | R | Section 5.8.1.10 | | |||
| lease_time | 10 | nfs_lease4 | RD | Section 5.8.1.11 | | | lease_time | 10 | nfs_lease4 | R | Section 5.8.1.11 | | |||
| rdattr_error | 11 | enum | RD | Section 5.8.1.12 | | | rdattr_error | 11 | enum | R | Section 5.8.1.12 | | |||
| filehandle | 19 | nfs_fh4 | RD | Section 5.8.1.13 | | | filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 | | |||
| suppattr_exclcreat | 75 | bitmap4 | RD | Section 5.8.1.14 | | | suppattr_exclcreat | 75 | bitmap4 | R | Section 5.8.1.14 | | |||
+--------------------+----+------------+-----+------------------+ | +--------------------+----+------------+-----+------------------+ | |||
Table 4 | Table 4 | |||
5.7. RECOMMENDED Attributes - List and Definition References | 5.7. RECOMMENDED Attributes - List and Definition References | |||
The RECOMMENDED attributes are defined in Table 5. The meanings of | The RECOMMENDED attributes are defined in Table 5. The meanings of | |||
the column headers are the same as Table 4; see Section 5.6 for the | the column headers are the same as Table 4; see Section 5.6 for the | |||
meanings. | meanings. | |||
+--------------------+----+----------------+-----+------------------+ | +--------------------+----+----------------+-----+------------------+ | |||
| Name | Id | Data Type | Acc | Defined in: | | | Name | Id | Data Type | Acc | Defined in: | | |||
+--------------------+----+----------------+-----+------------------+ | +--------------------+----+----------------+-----+------------------+ | |||
| acl | 12 | nfsace4<> | R/W | Section 6.2.1 | | | acl | 12 | nfsace4<> | R W | Section 6.2.1 | | |||
| aclsupport | 13 | uint32_t | RD | Section 6.2.1.2 | | | aclsupport | 13 | uint32_t | R | Section 6.2.1.2 | | |||
| archive | 14 | bool | R/W | Section 5.8.2.1 | | | archive | 14 | bool | R W | Section 5.8.2.1 | | |||
| cansettime | 15 | bool | RD | Section 5.8.2.2 | | | cansettime | 15 | bool | R | Section 5.8.2.2 | | |||
| case_insensitive | 16 | bool | RD | Section 5.8.2.3 | | | case_insensitive | 16 | bool | R | Section 5.8.2.3 | | |||
| case_preserving | 17 | bool | RD | Section 5.8.2.4 | | | case_preserving | 17 | bool | R | Section 5.8.2.4 | | |||
| change_policy | 60 | chg_policy4 | RD | Section 5.8.2.5 | | | change_policy | 60 | chg_policy4 | R | Section 5.8.2.5 | | |||
| chown_restricted | 18 | bool | RD | Section 5.8.2.6 | | | chown_restricted | 18 | bool | R | Section 5.8.2.6 | | |||
| dacl | 58 | nfsacl41 | R/W | Section 6.2.2 | | | dacl | 58 | nfsacl41 | R W | Section 6.2.2 | | |||
| dir_notif_delay | 56 | nfstime4 | RD | Section 5.11.1 | | | dir_notif_delay | 56 | nfstime4 | R | Section 5.11.1 | | |||
| dirent_notif_delay | 57 | nfstime4 | RD | Section 5.11.2 | | | dirent_notif_delay | 57 | nfstime4 | R | Section 5.11.2 | | |||
| fileid | 20 | uint64_t | RD | Section 5.8.2.7 | | | fileid | 20 | uint64_t | R | Section 5.8.2.7 | | |||
| files_avail | 21 | uint64_t | RD | Section 5.8.2.8 | | | files_avail | 21 | uint64_t | R | Section 5.8.2.8 | | |||
| files_free | 22 | uint64_t | RD | Section 5.8.2.9 | | | files_free | 22 | uint64_t | R | Section 5.8.2.9 | | |||
| files_total | 23 | uint64_t | RD | Section 5.8.2.10 | | | files_total | 23 | uint64_t | R | Section 5.8.2.10 | | |||
| fs_charset_cap | 76 | uint32_t | RD | Section 5.8.2.11 | | | fs_charset_cap | 76 | uint32_t | R | Section 5.8.2.11 | | |||
| fs_layout_type | 62 | layouttype4<> | RD | Section 5.12.1 | | | fs_layout_type | 62 | layouttype4<> | R | Section 5.12.1 | | |||
| fs_locations | 24 | fs_locations | RD | Section 5.8.2.12 | | | fs_locations | 24 | fs_locations | R | Section 5.8.2.12 | | |||
| fs_locations_info | 67 | * | RD | Section 5.8.2.13 | | | fs_locations_info | 67 | * | R | Section 5.8.2.13 | | |||
| fs_status | 61 | fs4_status | RD | Section 5.8.2.14 | | | fs_status | 61 | fs4_status | R | Section 5.8.2.14 | | |||
| hidden | 25 | bool | R/W | Section 5.8.2.15 | | | hidden | 25 | bool | R W | Section 5.8.2.15 | | |||
| homogeneous | 26 | bool | RD | Section 5.8.2.16 | | | homogeneous | 26 | bool | R | Section 5.8.2.16 | | |||
| layout_alignment | 66 | uint32_t | RD | Section 5.12.2 | | | layout_alignment | 66 | uint32_t | R | Section 5.12.2 | | |||
| layout_blksize | 65 | uint32_t | RD | Section 5.12.3 | | | layout_blksize | 65 | uint32_t | R | Section 5.12.3 | | |||
| layout_hint | 63 | layouthint4 | WRT | Section 5.12.4 | | | layout_hint | 63 | layouthint4 | W | Section 5.12.4 | | |||
| layout_type | 64 | layouttype4<> | RD | Section 5.12.5 | | | layout_type | 64 | layouttype4<> | R | Section 5.12.5 | | |||
| maxfilesize | 27 | uint64_t | RD | Section 5.8.2.17 | | | maxfilesize | 27 | uint64_t | R | Section 5.8.2.17 | | |||
| maxlink | 28 | uint32_t | RD | Section 5.8.2.18 | | | maxlink | 28 | uint32_t | R | Section 5.8.2.18 | | |||
| maxname | 29 | uint32_t | RD | Section 5.8.2.19 | | | maxname | 29 | uint32_t | R | Section 5.8.2.19 | | |||
| maxread | 30 | uint64_t | RD | Section 5.8.2.20 | | | maxread | 30 | uint64_t | R | Section 5.8.2.20 | | |||
| maxwrite | 31 | uint64_t | RD | Section 5.8.2.21 | | | maxwrite | 31 | uint64_t | R | Section 5.8.2.21 | | |||
| mdsthreshold | 68 | mdsthreshold4 | RD | Section 5.12.6 | | | mdsthreshold | 68 | mdsthreshold4 | R | Section 5.12.6 | | |||
| mimetype | 32 | utf8<> | R/W | Section 5.8.2.22 | | | mimetype | 32 | utf8<> | R W | Section 5.8.2.22 | | |||
| mode | 33 | mode4 | R/W | Section 6.2.4 | | | mode | 33 | mode4 | R W | Section 6.2.4 | | |||
| mode_set_masked | 74 | mode_masked4 | WRT | Section 6.2.5 | | | mode_set_masked | 74 | mode_masked4 | W | Section 6.2.5 | | |||
| mounted_on_fileid | 55 | uint64_t | RD | Section 5.8.2.23 | | | mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.23 | | |||
| no_trunc | 34 | bool | RD | Section 5.8.2.24 | | | no_trunc | 34 | bool | R | Section 5.8.2.24 | | |||
| numlinks | 35 | uint32_t | RD | Section 5.8.2.25 | | | numlinks | 35 | uint32_t | R | Section 5.8.2.25 | | |||
| owner | 36 | utf8<> | R/W | Section 5.8.2.26 | | | owner | 36 | utf8<> | R W | Section 5.8.2.26 | | |||
| owner_group | 37 | utf8<> | R/W | Section 5.8.2.27 | | | owner_group | 37 | utf8<> | R W | Section 5.8.2.27 | | |||
| quota_avail_hard | 38 | uint64_t | RD | Section 5.8.2.28 | | | quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.28 | | |||
| quota_avail_soft | 39 | uint64_t | RD | Section 5.8.2.29 | | | quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.29 | | |||
| quota_used | 40 | uint64_t | RD | Section 5.8.2.30 | | | quota_used | 40 | uint64_t | R | Section 5.8.2.30 | | |||
| rawdev | 41 | specdata4 | RD | Section 5.8.2.31 | | | rawdev | 41 | specdata4 | R | Section 5.8.2.31 | | |||
| retentevt_get | 71 | retention_get4 | RD | Section 5.13.3 | | | retentevt_get | 71 | retention_get4 | R | Section 5.13.3 | | |||
| retentevt_set | 72 | retention_set4 | WRT | Section 5.13.4 | | | retentevt_set | 72 | retention_set4 | W | Section 5.13.4 | | |||
| retention_get | 69 | retention_get4 | RD | Section 5.13.1 | | | retention_get | 69 | retention_get4 | R | Section 5.13.1 | | |||
| retention_hold | 73 | uint64_t | R/W | Section 5.13.5 | | | retention_hold | 73 | uint64_t | R W | Section 5.13.5 | | |||
| retention_set | 70 | retention_set4 | WRT | Section 5.13.2 | | | retention_set | 70 | retention_set4 | W | Section 5.13.2 | | |||
| sacl | 59 | nfsacl41 | R/W | Section 6.2.3 | | | sacl | 59 | nfsacl41 | R W | Section 6.2.3 | | |||
| space_avail | 42 | uint64_t | RD | Section 5.8.2.32 | | | space_avail | 42 | uint64_t | R | Section 5.8.2.32 | | |||
| space_free | 43 | uint64_t | RD | Section 5.8.2.33 | | | space_free | 43 | uint64_t | R | Section 5.8.2.33 | | |||
| space_total | 44 | uint64_t | RD | Section 5.8.2.34 | | | space_total | 44 | uint64_t | R | Section 5.8.2.34 | | |||
| space_used | 45 | uint64_t | RD | Section 5.8.2.35 | | | space_used | 45 | uint64_t | R | Section 5.8.2.35 | | |||
| system | 46 | bool | R/W | Section 5.8.2.36 | | | system | 46 | bool | R W | Section 5.8.2.36 | | |||
| time_access | 47 | nfstime4 | RD | Section 5.8.2.37 | | | time_access | 47 | nfstime4 | R | Section 5.8.2.37 | | |||
| time_access_set | 48 | settime4 | WRT | Section 5.8.2.38 | | | time_access_set | 48 | settime4 | W | Section 5.8.2.38 | | |||
| time_backup | 49 | nfstime4 | R/W | Section 5.8.2.39 | | | time_backup | 49 | nfstime4 | R W | Section 5.8.2.39 | | |||
| time_create | 50 | nfstime4 | R/W | Section 5.8.2.40 | | | time_create | 50 | nfstime4 | R W | Section 5.8.2.40 | | |||
| time_delta | 51 | nfstime4 | RD | Section 5.8.2.41 | | | time_delta | 51 | nfstime4 | R | Section 5.8.2.41 | | |||
| time_metadata | 52 | nfstime4 | RD | Section 5.8.2.42 | | | time_metadata | 52 | nfstime4 | R | Section 5.8.2.42 | | |||
| time_modify | 53 | nfstime4 | RD | Section 5.8.2.43 | | | time_modify | 53 | nfstime4 | R | Section 5.8.2.43 | | |||
| time_modify_set | 54 | settime4 | WRT | Section 5.8.2.44 | | | time_modify_set | 54 | settime4 | W | Section 5.8.2.44 | | |||
+--------------------+----+----------------+-----+------------------+ | +--------------------+----+----------------+-----+------------------+ | |||
Table 5 | Table 5 | |||
* fs_locations_info4 | * fs_locations_info4 | |||
5.8. Attribute Definitions | 5.8. Attribute Definitions | |||
5.8.1. Definitions of REQUIRED Attributes | 5.8.1. Definitions of REQUIRED Attributes | |||
skipping to change at page 350, line 20 | skipping to change at page 351, line 20 | |||
| | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_MLINK, | | | | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_MLINK, | | |||
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | |||
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | |||
| | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, | | | | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, | | |||
| | NFS4ERR_OP_NOT_IN_SESSION, | | | | NFS4ERR_OP_NOT_IN_SESSION, | | |||
| | NFS4ERR_REP_TOO_BIG, | | | | NFS4ERR_REP_TOO_BIG, | | |||
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | |||
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_ROFS, | | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_ROFS, | | |||
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | |||
| | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | | |||
| | NFS4ERR_WRONG_TYPE, NFS4ERR_XDEV | | | | NFS4ERR_WRONGSEC, NFS4ERR_WRONG_TYPE, | | |||
| | NFS4ERR_XDEV | | ||||
| LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | |||
| | NFS4ERR_BADXDR, NFS4ERR_BAD_RANGE, | | | | NFS4ERR_BADXDR, NFS4ERR_BAD_RANGE, | | |||
| | NFS4ERR_BAD_STATEID, NFS4ERR_DEADLOCK, | | | | NFS4ERR_BAD_STATEID, NFS4ERR_DEADLOCK, | | |||
| | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | |||
| | NFS4ERR_DENIED, NFS4ERR_EXPIRED, | | | | NFS4ERR_DENIED, NFS4ERR_EXPIRED, | | |||
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | |||
| | NFS4ERR_INVAL, NFS4ERR_ISDIR, | | | | NFS4ERR_INVAL, NFS4ERR_ISDIR, | | |||
| | NFS4ERR_LOCK_NOTSUPP, NFS4ERR_LOCK_RANGE, | | | | NFS4ERR_LOCK_NOTSUPP, NFS4ERR_LOCK_RANGE, | | |||
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | |||
| | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, | | | | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, | | |||
skipping to change at page 356, line 44 | skipping to change at page 357, line 44 | |||
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | |||
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | |||
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, | | | | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, | | |||
| | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, | | | | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, | | |||
| | NFS4ERR_NOTEMPTY, | | | | NFS4ERR_NOTEMPTY, | | |||
| | NFS4ERR_OP_NOT_IN_SESSION, | | | | NFS4ERR_OP_NOT_IN_SESSION, | | |||
| | NFS4ERR_REP_TOO_BIG, | | | | NFS4ERR_REP_TOO_BIG, | | |||
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | |||
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_ROFS, | | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_ROFS, | | |||
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | |||
| | NFS4ERR_TOO_MANY_OPS, NFS4ERR_XDEV | | | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC, | | |||
| | NFS4ERR_XDEV | | ||||
| RENEW | NFS4ERR_NOTSUPP | | | RENEW | NFS4ERR_NOTSUPP | | |||
| RESTOREFH | NFS4ERR_DEADSESSION, NFS4ERR_FHEXPIRED, | | | RESTOREFH | NFS4ERR_DEADSESSION, NFS4ERR_FHEXPIRED, | | |||
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | |||
| | NFS4ERR_OP_NOT_IN_SESSION, | | | | NFS4ERR_OP_NOT_IN_SESSION, | | |||
| | NFS4ERR_REP_TOO_BIG, | | | | NFS4ERR_REP_TOO_BIG, | | |||
| | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | |||
| | NFS4ERR_REQ_TOO_BIG, NFS4ERR_SERVERFAULT, | | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_SERVERFAULT, | | |||
| | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, | | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, | | |||
| | NFS4ERR_WRONGSEC | | | | NFS4ERR_WRONGSEC | | |||
| SAVEFH | NFS4ERR_DEADSESSION, NFS4ERR_FHEXPIRED, | | | SAVEFH | NFS4ERR_DEADSESSION, NFS4ERR_FHEXPIRED, | | |||
skipping to change at page 375, line 46 | skipping to change at page 376, line 46 | |||
| | SECINFO, SECINFO_NO_NAME, | | | | SECINFO, SECINFO_NO_NAME, | | |||
| | SEQUENCE, SETATTR, SET_SSV, | | | | SEQUENCE, SETATTR, SET_SSV, | | |||
| | TEST_STATEID, VERIFY, | | | | TEST_STATEID, VERIFY, | | |||
| | WANT_DELEGATION, WRITE | | | | WANT_DELEGATION, WRITE | | |||
| NFS4ERR_UNKNOWN_LAYOUTTYPE | CB_LAYOUTRECALL, | | | NFS4ERR_UNKNOWN_LAYOUTTYPE | CB_LAYOUTRECALL, | | |||
| | GETDEVICEINFO, GETDEVICELIST, | | | | GETDEVICEINFO, GETDEVICELIST, | | |||
| | LAYOUTCOMMIT, LAYOUTGET, | | | | LAYOUTCOMMIT, LAYOUTGET, | | |||
| | LAYOUTRETURN, NVERIFY, | | | | LAYOUTRETURN, NVERIFY, | | |||
| | SETATTR, VERIFY | | | | SETATTR, VERIFY | | |||
| NFS4ERR_UNSAFE_COMPOUND | CREATE, OPEN, OPENATTR | | | NFS4ERR_UNSAFE_COMPOUND | CREATE, OPEN, OPENATTR | | |||
| NFS4ERR_WRONGSEC | LOOKUP, LOOKUPP, OPEN, PUTFH, | | | NFS4ERR_WRONGSEC | LINK, LOOKUP, LOOKUPP, OPEN, | | |||
| | PUTPUBFH, PUTROOTFH, | | | | PUTFH, PUTPUBFH, PUTROOTFH, | | |||
| | RESTOREFH | | | | RENAME, RESTOREFH | | |||
| NFS4ERR_WRONG_CRED | CLOSE, CREATE_SESSION, | | | NFS4ERR_WRONG_CRED | CLOSE, CREATE_SESSION, | | |||
| | DELEGPURGE, DELEGRETURN, | | | | DELEGPURGE, DELEGRETURN, | | |||
| | DESTROY_CLIENTID, | | | | DESTROY_CLIENTID, | | |||
| | DESTROY_SESSION, | | | | DESTROY_SESSION, | | |||
| | FREE_STATEID, LAYOUTCOMMIT, | | | | FREE_STATEID, LAYOUTCOMMIT, | | |||
| | LAYOUTRETURN, LOCK, LOCKT, | | | | LAYOUTRETURN, LOCK, LOCKT, | | |||
| | LOCKU, OPEN_DOWNGRADE, | | | | LOCKU, OPEN_DOWNGRADE, | | |||
| | RECLAIM_COMPLETE | | | | RECLAIM_COMPLETE | | |||
| NFS4ERR_WRONG_TYPE | CB_LAYOUTRECALL, | | | NFS4ERR_WRONG_TYPE | CB_LAYOUTRECALL, | | |||
| | CB_PUSH_DELEG, COMMIT, | | | | CB_PUSH_DELEG, COMMIT, | | |||
skipping to change at page 422, line 5 | skipping to change at page 423, line 5 | |||
Contrast this with NFSv3, which would first send a GETATTR in one | Contrast this with NFSv3, which would first send a GETATTR in one | |||
request/reply round trip, and then if attributes indicated that the | request/reply round trip, and then if attributes indicated that the | |||
client's cache was stale, then send a READ in another request/reply | client's cache was stale, then send a READ in another request/reply | |||
round trip. | round trip. | |||
In the case that a RECOMMENDED attribute is specified in the NVERIFY | In the case that a RECOMMENDED attribute is specified in the NVERIFY | |||
operation and the server does not support that attribute for the file | operation and the server does not support that attribute for the file | |||
system object, the error NFS4ERR_ATTRNOTSUPP is returned to the | system object, the error NFS4ERR_ATTRNOTSUPP is returned to the | |||
client. | client. | |||
When the attribute rdattr_error or any write-only attribute (e.g. | When the attribute rdattr_error or any set-only attribute (e.g. | |||
time_modify_set) is specified, the error NFS4ERR_INVAL is returned to | time_modify_set) is specified, the error NFS4ERR_INVAL is returned to | |||
the client. | the client. | |||
18.16. Operation 18: OPEN - Open a Regular File | 18.16. Operation 18: OPEN - Open a Regular File | |||
18.16.1. ARGUMENTS | 18.16.1. ARGUMENTS | |||
/* | /* | |||
* Various definitions for OPEN | * Various definitions for OPEN | |||
*/ | */ | |||
skipping to change at page 443, line 27 | skipping to change at page 444, line 27 | |||
Valid values for the share_deny field are: OPEN4_SHARE_DENY_NONE, | Valid values for the share_deny field are: OPEN4_SHARE_DENY_NONE, | |||
OPEN4_SHARE_DENY_READ, OPEN4_SHARE_DENY_WRITE, or | OPEN4_SHARE_DENY_READ, OPEN4_SHARE_DENY_WRITE, or | |||
OPEN4_SHARE_DENY_BOTH. If the client specifies other values, the | OPEN4_SHARE_DENY_BOTH. If the client specifies other values, the | |||
server MUST reply with NFS4ERR_INVAL. | server MUST reply with NFS4ERR_INVAL. | |||
After checking for valid values of share_access and share_deny, the | After checking for valid values of share_access and share_deny, the | |||
server replaces the current access and deny modes on the file with | server replaces the current access and deny modes on the file with | |||
share_access and share_deny subject to the following constraints: | share_access and share_deny subject to the following constraints: | |||
o The bits in share_access MUST equal the union of the share_access | o The bits in share_access SHOULD equal the union of the | |||
bits (not including OPEN4_SHARE_WANT_* bits) specified for some | share_access bits (not including OPEN4_SHARE_WANT_* bits) | |||
subset of the OPENs in effect for the current open-owner on the | ||||
current file. | ||||
o The bits in share_deny MUST equal the union of the share_deny bits | ||||
specified for some subset of the OPENs in effect for the current | specified for some subset of the OPENs in effect for the current | |||
open-owner on the current file. | open-owner on the current file. | |||
If the above constraints are not respected, the server MUST return | o The bits in share_deny SHOULD equal the union of the share_deny | |||
bits specified for some subset of the OPENs in effect for the | ||||
current open-owner on the current file. | ||||
If the above constraints are not respected, the server SHOULD return | ||||
the error NFS4ERR_INVAL. Since share_access and share_deny bits | the error NFS4ERR_INVAL. Since share_access and share_deny bits | |||
should be subsets of those already granted, short of a defect in the | should be subsets of those already granted, short of a defect in the | |||
client or server implementation, it is not possible for the | client or server implementation, it is not possible for the | |||
OPEN_DOWNGRADE request to be denied because of conflicting share | OPEN_DOWNGRADE request to be denied because of conflicting share | |||
reservations. | reservations. | |||
The seqid argument is not used in NFSv4.1, MAY be any value, and MUST | The seqid argument is not used in NFSv4.1, MAY be any value, and MUST | |||
be ignored by the server. | be ignored by the server. | |||
On success, the current filehandle retains its value. | On success, the current filehandle retains its value. | |||
skipping to change at page 457, line 34 | skipping to change at page 458, line 34 | |||
default: | default: | |||
void; | void; | |||
}; | }; | |||
18.26.3. DESCRIPTION | 18.26.3. DESCRIPTION | |||
The RENAME operation renames the object identified by oldname in the | The RENAME operation renames the object identified by oldname in the | |||
source directory corresponding to the saved filehandle, as set by the | source directory corresponding to the saved filehandle, as set by the | |||
SAVEFH operation, to newname in the target directory corresponding to | SAVEFH operation, to newname in the target directory corresponding to | |||
the current filehandle. The operation is required to be atomic to | the current filehandle. The operation is required to be atomic to | |||
the client. Source and target directories must reside on the same | the client. Source and target directories MUST reside on the same | |||
file system on the server. On success, the current filehandle will | file system on the server. On success, the current filehandle will | |||
continue to be the target directory. | continue to be the target directory. | |||
If the target directory already contains an entry with the name, | If the target directory already contains an entry with the name, | |||
newname, the source object must be compatible with the target: either | newname, the source object MUST be compatible with the target: either | |||
both are non-directories or both are directories and the target must | both are non-directories or both are directories and the target MUST | |||
be empty. If compatible, the existing target is removed before the | be empty. If compatible, the existing target is removed before the | |||
rename occurs or preferably as part of the rename and atomic with it. | rename occurs or preferably as part of the rename and atomic with it. | |||
See Section 18.25.4 for client and server actions whenever a target | See Section 18.25.4 for client and server actions whenever a target | |||
is removed. Note however that when the removal is performed | is removed. Note however that when the removal is performed | |||
atomically with the rename, certain parts of the removal described | atomically with the rename, certain parts of the removal described | |||
there are integrated with the rename. For example, notification of | there are integrated with the rename. For example, notification of | |||
the removal will not be via a NOTIFY4_REMOVE_ENTRY but will be | the removal will not be via a NOTIFY4_REMOVE_ENTRY but will be | |||
indicated as part of the NOTIFY4_ADD_ENTRY or NOTIFY4_RENAME_ENTRY | indicated as part of the NOTIFY4_ADD_ENTRY or NOTIFY4_RENAME_ENTRY | |||
generated by the rename. | generated by the rename. | |||
If the source object and the target are not compatible or if the | If the source object and the target are not compatible or if the | |||
target is a directory but not empty, the server will return the | target is a directory but not empty, the server will return the | |||
error, NFS4ERR_EXIST. | error, NFS4ERR_EXIST. | |||
If oldname and newname both refer to the same file (e.g. they might | If oldname and newname both refer to the same file (e.g. they might | |||
be hard links of each other), then RENAME MUST perform no action and | be hard links of each other), then unless the file is open (see | |||
return NFS4_OK. | Section 18.26.4), RENAME MUST perform no action and return NFS4_OK. | |||
For both directories involved in the RENAME, the server returns | For both directories involved in the RENAME, the server returns | |||
change_info4 information. With the atomic field of the change_info4 | change_info4 information. With the atomic field of the change_info4 | |||
data type, the server will indicate if the before and after change | data type, the server will indicate if the before and after change | |||
attributes were obtained atomically with respect to the rename. | attributes were obtained atomically with respect to the rename. | |||
If the oldname refers to a named attribute and the saved and current | If oldname refers to a named attribute and the saved and current | |||
filehandles refer to different file system objects, the server will | filehandles refer to different file system objects, the server will | |||
return NFS4ERR_XDEV just as if the saved and current filehandles | return NFS4ERR_XDEV just as if the saved and current filehandles | |||
represented directories on different file systems. | represented directories on different file systems. | |||
If the oldname or newname has a length of 0 (zero), or if oldname or | If oldname or newname have a length of 0 (zero), or if oldname or | |||
newname does not obey the UTF-8 definition, the error NFS4ERR_INVAL | newname do not obey the UTF-8 definition, the error NFS4ERR_INVAL | |||
will be returned. | will be returned. | |||
18.26.4. IMPLEMENTATION | 18.26.4. IMPLEMENTATION | |||
The server MAY impose restrictions on the RENAME operation such that | The server MAY impose restrictions on the RENAME operation such that | |||
RENAME may not be done when the file being renamed is open or when | RENAME may not be done when the file being renamed is open or when | |||
that open is done by particular protocols, or with particular options | that open is done by particular protocols, or with particular options | |||
or access modes. Similar restrictions may be applied when a file | or access modes. Similar restrictions may be applied when a file | |||
exists with the target name and is open. When RENAME is rejected | exists with the target name and is open. When RENAME is rejected | |||
because of such restrictions, the error NFS4ERR_FILE_OPEN is | because of such restrictions, the error NFS4ERR_FILE_OPEN is | |||
returned. | returned. | |||
When oldname and rename refer to the same file and that file is open | When oldname and rename refer to the same file and that file is open | |||
is such a fashion that RENAME would normally be rejected with | in a fashion such that RENAME would normally be rejected with | |||
NFS4ERR_FILE_OPEN, it SHOULD be rejected and the error returned in | NFS4ERR_FILE_OPEN if oldname and newname were different files, then | |||
the same way as would have been done if oldname and newname did not | RENAME SHOULD be rejected with NFS4ERR_FILE_OPEN. | |||
refer to the same file. | ||||
If a server does implement such restrictions and those restrictions | If a server does implement such restrictions and those restrictions | |||
include cases of NFSv4 opens preventing successful execution of a | include cases of NFSv4 opens preventing successful execution of a | |||
rename, the server needs to recall any delegations which could hide | rename, the server needs to recall any delegations which could hide | |||
the existence of opens relevant to that decision. This is because of | the existence of opens relevant to that decision. This is because | |||
the fact that when a client holds a delegation, the server need not | when a client holds a delegation, the server might not have an | |||
have accurate picture of the opens for that client, since the client | accurate account of the opens for that client, since the client may | |||
may execute OPENs and CLOSEs locally. The RENAME operation must be | execute OPENs and CLOSEs locally. The RENAME operation need only be | |||
delayed only until a definitive result can be obtained. For example, | delayed until a definitive result can be obtained. For example, if | |||
if there are multiple delegations and one of them establishes an open | there are multiple delegations and one of them establishes an open | |||
whose presence would prevent the rename, given the server's | whose presence would prevent the rename, given the server's | |||
semantics, NFS4ERR_FILE_OPEN may be returned to the caller as soon as | semantics, NFS4ERR_FILE_OPEN may be returned to the caller as soon as | |||
that delegation is returned without waiting for other delegations to | that delegation is returned without waiting for other delegations to | |||
be returned. Similarly, if such opens are not associated with | be returned. Similarly, if such opens are not associated with | |||
delegations, NFS4ERR_FILE_OPEN can be returned immediately with no | delegations, NFS4ERR_FILE_OPEN can be returned immediately with no | |||
delegation recall being done. | delegation recall being done. | |||
If the current filehandle or the saved filehandle designates a | If the current filehandle or the saved filehandle designate a | |||
directory for which another client holds a directory delegation, | directory for which another client holds a directory delegation, | |||
then, unless the delegation is such that the situation can be | then, unless the situation can be resolved by sending a notification, | |||
resolved by sending a notification, the delegation must be recalled, | the delegation MUST be recalled, and the operation cannot proceed | |||
and the operation cannot proceed until the delegation is returned or | until the delegation is returned or revoked. Except where this | |||
revoked. Except where this happens very quickly, one or more | happens very quickly, one or more NFS4ERR_DELAY errors will be | |||
NFS4ERR_DELAY errors will be returned to requests made while | returned to requests made while delegation remains outstanding. | |||
delegation remains outstanding. | ||||
When the current and saved filehandles are the same and they | When the current and saved filehandles are the same and they | |||
designate a directory for which one or more directory delegations | designate a directory for which one or more directory delegations | |||
exist, then, when those delegations request such notifications, a | exist, then, when those delegations request such notifications, a | |||
notification of type NOTIFY4_RENAME_ENTRY will be generated as a | notification of type NOTIFY4_RENAME_ENTRY will be generated as a | |||
result of this operation. When oldname and rename refer to the same | result of this operation. When oldname and rename refer to the same | |||
file, it is not required that such a notification be generated. When | file, no notification is generated (because as Section 18.26.3 | |||
a file is removed because it has the same name as the target, if that | states, the server MUST take no action). When a file is removed | |||
removal is done atomically with the rename, a NOTIFY4_REMOVE_ENTRY | because it has the same name as the target, if that removal is done | |||
notification will not be generated. Instead, the deletion of the | atomically with the rename, a NOTIFY4_REMOVE_ENTRY notification will | |||
file will be reported as part of the NOTIFY4_RENAME_ENTRY | not be generated. Instead, the deletion of the file will be reported | |||
notification. | as part of the NOTIFY4_RENAME_ENTRY notification. | |||
When the current and saved filehandles are not the same: | When the current and saved filehandles are not the same: | |||
o If the current filehandle designates a directory for which one or | o If the current filehandle designates a directory for which one or | |||
more directory delegations exist, then, when those delegations | more directory delegations exist, then, when those delegations | |||
request such notifications, NOTIFY4_ADD_ENTRY will be generated as | request such notifications, NOTIFY4_ADD_ENTRY will be generated as | |||
a result of this operation. When a file is removed because it has | a result of this operation. When a file is removed because it has | |||
the same name as the target, if that removal is done atomically | the same name as the target, if that removal is done atomically | |||
with the rename, a NOTIFY4_REMOVE_ENTRY notification will not be | with the rename, a NOTIFY4_REMOVE_ENTRY notification will not be | |||
generated. Instead, the deletion of the file will be reported as | generated. Instead, the deletion of the file will be reported as | |||
part of the NOTIFY4_ADD_ENTRY notification. | part of the NOTIFY4_ADD_ENTRY notification. | |||
o If the saved filehandle designates a directory for which one or | o If the saved filehandle designates a directory for which one or | |||
more directory delegations exist, then, when those delegations | more directory delegations exist, then, when those delegations | |||
request such notifications, NOTIFY4_REMOVE_ENTRY will be generated | request such notifications, NOTIFY4_REMOVE_ENTRY will be generated | |||
as a result of this operation. | as a result of this operation. | |||
If the object being renamed has a file delegation which is held by a | If the object being renamed has file delegations held by clients | |||
client other than the one doing the RENAME, the delegation(s) must be | other than the one doing the RENAME, the delegations MUST be | |||
recalled, and the operation cannot proceed until each such delegation | recalled, and the operation cannot proceed until each such delegation | |||
is returned or revoked. Note that in the case of multiply linked | is returned or revoked. Note that in the case of multiply linked | |||
files, the delegation recall requirement applies even if the | files, the delegation recall requirement applies even if the | |||
delegation was obtained through a different name than the one being | delegation was obtained through a different name than the one being | |||
renamed. In all cases in which delegations are recalled, the server | renamed. In all cases in which delegations are recalled, the server | |||
is likely to return one or more NFS4ERR_DELAY error while the | is likely to return one or more NFS4ERR_DELAY error while the | |||
delegation(s) remains outstanding, although it may, if the returns | delegation(s) remains outstanding, although it may, if the returns | |||
happen quickly, not do that. | happen quickly, not do that. | |||
The RENAME operation must be atomic to the client. The statement | The RENAME operation must be atomic to the client. The statement | |||
"source and target directories must reside on the same file system on | "source and target directories MUST reside on the same file system on | |||
the server" means that the fsid fields in the attributes for the | the server" means that the fsid fields in the attributes for the | |||
directories are the same. If they reside on different file systems, | directories are the same. If they reside on different file systems, | |||
the error, NFS4ERR_XDEV, is returned. | the error, NFS4ERR_XDEV, is returned. | |||
Based on the value of the fh_expire_type attribute for the object, | Based on the value of the fh_expire_type attribute for the object, | |||
the filehandle may or may not expire on a RENAME. However, server | the filehandle may or may not expire on a RENAME. However, server | |||
implementors are strongly encouraged to attempt to keep filehandles | implementors are strongly encouraged to attempt to keep filehandles | |||
from expiring in this fashion. | from expiring in this fashion. | |||
On some servers, the file names "." and ".." are illegal as either | On some servers, the file names "." and ".." are illegal as either | |||
skipping to change at page 463, line 46 | skipping to change at page 464, line 46 | |||
default: | default: | |||
void; | void; | |||
}; | }; | |||
18.29.3. DESCRIPTION | 18.29.3. DESCRIPTION | |||
The SECINFO operation is used by the client to obtain a list of valid | The SECINFO operation is used by the client to obtain a list of valid | |||
RPC authentication flavors for a specific directory filehandle, file | RPC authentication flavors for a specific directory filehandle, file | |||
name pair. SECINFO should apply the same access methodology used for | name pair. SECINFO should apply the same access methodology used for | |||
LOOKUP when evaluating the name. Therefore, if the requester does | LOOKUP when evaluating the name. Therefore, if the requester does | |||
not have the appropriate access to LOOKUP the name then SECINFO must | not have the appropriate access to LOOKUP the name then SECINFO MUST | |||
behave the same way and return NFS4ERR_ACCESS. | behave the same way and return NFS4ERR_ACCESS. | |||
The result will contain an array which represents the security | The result will contain an array which represents the security | |||
mechanisms available, with an order corresponding to the server's | mechanisms available, with an order corresponding to the server's | |||
preferences, the most preferred being first in the array. The client | preferences, the most preferred being first in the array. The client | |||
is free to pick whatever security mechanism it both desires and | is free to pick whatever security mechanism it both desires and | |||
supports, or to pick in the server's preference order the first one | supports, or to pick in the server's preference order the first one | |||
it supports. The array entries are represented by the secinfo4 | it supports. The array entries are represented by the secinfo4 | |||
structure. The field 'flavor' will contain a value of AUTH_NONE, | structure. The field 'flavor' will contain a value of AUTH_NONE, | |||
AUTH_SYS (as defined in RFC1831 [3]), or RPCSEC_GSS (as defined in | AUTH_SYS (as defined in RFC1831 [3]), or RPCSEC_GSS (as defined in | |||
RFC2203 [4]). The field flavor can also any other security flavor | RFC2203 [4]). The field flavor can also be any other security flavor | |||
registered with IANA. | registered with IANA. | |||
For the flavors AUTH_NONE and AUTH_SYS, no additional security | For the flavors AUTH_NONE and AUTH_SYS, no additional security | |||
information is returned. The same is true of many (if not most) | information is returned. The same is true of many (if not most) | |||
other security flavors, including AUTH_DH. For a return value of | other security flavors, including AUTH_DH. For a return value of | |||
RPCSEC_GSS, a security triple is returned that contains the mechanism | RPCSEC_GSS, a security triple is returned that contains the mechanism | |||
object id (as defined in RFC2743 [7]), the quality of protection (as | object id (as defined in RFC2743 [7]), the quality of protection (as | |||
defined in RFC2743 [7]) and the service type (as defined in RFC2203 | defined in RFC2743 [7]) and the service type (as defined in RFC2203 | |||
[4]). It is possible for SECINFO to return multiple entries with | [4]). It is possible for SECINFO to return multiple entries with | |||
flavor equal to RPCSEC_GSS with different security triple values. | flavor equal to RPCSEC_GSS with different security triple values. | |||
On success, the current filehandle is consumed (see | On success, the current filehandle is consumed (see | |||
Section 2.6.3.1.8), and if the next operation after SECINFO tries to | Section 2.6.3.1.1.8), and if the next operation after SECINFO tries | |||
use the current filehandle, that operation will fail with the status | to use the current filehandle, that operation will fail with the | |||
NFS4ERR_NOFILEHANDLE. | status NFS4ERR_NOFILEHANDLE. | |||
If the name has a length of 0 (zero), or if name does not obey the | If the name has a length of 0 (zero), or if name does not obey the | |||
UTF-8 definition, the error NFS4ERR_INVAL will be returned. | UTF-8 definition (assuming UTF-8 capabilities are enabled, see | |||
Section 14.4), the error NFS4ERR_INVAL will be returned. | ||||
See Section 2.6 for additional information on the use of SECINFO. | ||||
18.29.4. IMPLEMENTATION | 18.29.4. IMPLEMENTATION | |||
The SECINFO operation is expected to be used by the NFS client when | The SECINFO operation is expected to be used by the NFS client when | |||
the error value of NFS4ERR_WRONGSEC is returned from another NFS | the error value of NFS4ERR_WRONGSEC is returned from another NFS | |||
operation. This signifies to the client that the server's security | operation. This signifies to the client that the server's security | |||
policy is different from what the client is currently using. At this | policy is different from what the client is currently using. At this | |||
point, the client is expected to obtain a list of possible security | point, the client is expected to obtain a list of possible security | |||
flavors and choose what best suits its policies. | flavors and choose what best suits its policies. | |||
As mentioned, the server's security policies will determine when a | As mentioned, the server's security policies will determine when a | |||
client request receives NFS4ERR_WRONGSEC. The operations which may | client request receives NFS4ERR_WRONGSEC. See Table 14 for a list | |||
receive this error are: LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, PUTPUBFH, | operations which can return NFS4ERR_WRONGSEC. In addition, when | |||
PUTROOTFH, RESTOREFH, RENAME, and indirectly READDIR. LINK and | READDIR returns attributes, the rdaddr_error (Section 5.8.1.12) can | |||
RENAME will only receive this error if the security used for the | contain NFS4ERR_WRONGSEC. Note that CREATE and REMOVE MUST NOT | |||
operation is inappropriate for saved filehandle. With the exception | return NFS4ERR_WRONGSEC. The rationale for CREATE is that unless the | |||
of READDIR, these operations represent the point at which the client | target name exists it cannot have a separate security policy from the | |||
can instantiate a filehandle into the "current filehandle" at the | parent directory, and the security policy of the parent was checked | |||
server. The filehandle is either provided by the client (PUTFH, | when its filehandle was injected into the COMPOUND request's | |||
PUTPUBFH, PUTROOTFH) or generated as a result of a name to filehandle | operations stream (for similar reasons, an OPEN operation that | |||
translation (LOOKUP and OPEN). RESTOREFH is different because the | creates the target MUST NOT return NFS4ERR_WRONGSEC). If the target | |||
filehandle is a result of a previous SAVEFH. Even though the | name exists, while it might have a separate security policy, that is | |||
filehandle, for RESTOREFH, might have previously passed the server's | irrelevant because CREATE MUST return NFS4ERR_EXIST. The rationale | |||
inspection for a security match, the server will check it again on | for REMOVE is that while that target might have separate security | |||
RESTOREFH to ensure that the security policy has not changed. | policy, the target is going to be removed, and so the the security | |||
policy of the parent trumps that of the object being removed. RENAME | ||||
and LINK MAY return NFS4ERR_WRONGSEC, but the NFS4ERR_WRONGSEC error | ||||
applies only to the saved filehandle (see Section 2.6.3.1.2). Any | ||||
NFS4ERR_WRONGSEC error on the current filehandle used by LINK and | ||||
RENAME MUST be returned by the PUTFH, PUTPUBFH, PUTROOTFH, or | ||||
RESTOREFH operation that injected the current filehandle. | ||||
If the client wants to resolve an error return of NFS4ERR_WRONGSEC, | With the exception of LINK and RENAME, the set of operations that can | |||
the following will occur: | return NFS4ERR_WRONGSEC represent the point at which the client can | |||
inject a filehandle into the "current filehandle" at the server. The | ||||
filehandle is either provided by the client (PUTFH, PUTPUBFH, | ||||
PUTROOTFH), generated as a result of a name to filehandle translation | ||||
(LOOKUP and OPEN), or generated from the saved filehandle via | ||||
RESTOREFH. As Section 2.6.3.1.1.1 states, a put filehandle operation | ||||
followed by SAVEFH MUST NOT return NFS4ERR_WRONGSEC. Thus the | ||||
RESTOREFH operation, under certain conditions (see Section 2.6.3.1.1) | ||||
is permitted to return NFS4ERR_WRONGSEC so that security policies can | ||||
be honored. | ||||
The READDIR operation will not directly return the NFS4ERR_WRONGSEC | ||||
error. However, if the READDIR request included a request for | ||||
attributes, it is possible that the READDIR request's security triple | ||||
did not match that of a directory entry. If this is the case and the | ||||
client has requested the rdattr_error attribute, the server will | ||||
return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. | ||||
To resolve an error return of NFS4ERR_WRONGSEC, the client does the | ||||
following: | ||||
o For LOOKUP and OPEN, the client will use SECINFO with the same | o For LOOKUP and OPEN, the client will use SECINFO with the same | |||
current filehandle and name as provided in the original LOOKUP or | current filehandle and name as provided in the original LOOKUP or | |||
OPEN to enumerate the available security triples. | OPEN to enumerate the available security triples. | |||
o For LINK, PUTFH, PUTROOTFH, PUTPUBFH, RENAME, and RESTOREFH, the | o For the rdattr_error, the client will use SECINFO with the same | |||
current filehandle as provided in the original READDIR. The name | ||||
passed to SECINFO will be that of the directory entry (as returned | ||||
from READDIR) that had the NFS4ERR_WRONGSEC error in the | ||||
rdattr_error attribute. | ||||
o For PUTFH, PUTROOTFH, PUTPUBFH, RESTOREFH, LINK, and RENAME, the | ||||
client will use SECINFO_NO_NAME { style = | client will use SECINFO_NO_NAME { style = | |||
SECINFO_STYLE4_CURRENT_FH }. The client will prefix the | SECINFO_STYLE4_CURRENT_FH }. The client will prefix the | |||
SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or | SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or | |||
PUTROOTFH operation that provides the filehandle originally | PUTROOTFH operation that provides the filehandle originally | |||
provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH, or for | provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH | |||
the failed LINK or RENAME, the SAVEFH. | operation. | |||
o NOTE: In NFSv4.0, the client was required to use SECINFO, and had | NOTE: In NFSv4.0, the client was required to use SECINFO, and had | |||
to reconstruct the parent of the original filehandle, and the | to reconstruct the parent of the original filehandle, and the | |||
component name of the original filehandle. | component name of the original filehandle. The introduction in | |||
NFSv4.1 of SECINFO_NO_NAME obviates the need for reconstruction. | ||||
o For LOOKUPP, the client will use SECINFO_NO_NAME { style = | o For LOOKUPP, the client will use SECINFO_NO_NAME { style = | |||
SECINFO_STYLE4_PARENT } and provide the filehandle with equals the | SECINFO_STYLE4_PARENT } and provide the filehandle which equals | |||
filehandle originally provided to LOOKUPP. | the filehandle originally provided to LOOKUPP. | |||
The READDIR operation will not directly return the NFS4ERR_WRONGSEC | ||||
error. However, if the READDIR request included a request for | ||||
attributes, it is possible that the READDIR request's security triple | ||||
did not match that of a directory entry. If this is the case and the | ||||
client has requested the rdattr_error attribute, the server will | ||||
return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. | ||||
See Section 21 for a discussion on the recommendations for security | See Section 21 for a discussion on the recommendations for the | |||
flavor used by SECINFO and SECINFO_NO_NAME. | security flavor used by SECINFO and SECINFO_NO_NAME. | |||
18.30. Operation 34: SETATTR - Set Attributes | 18.30. Operation 34: SETATTR - Set Attributes | |||
18.30.1. ARGUMENTS | 18.30.1. ARGUMENTS | |||
struct SETATTR4args { | struct SETATTR4args { | |||
/* CURRENT_FH: target object */ | /* CURRENT_FH: target object */ | |||
stateid4 stateid; | stateid4 stateid; | |||
fattr4 obj_attributes; | fattr4 obj_attributes; | |||
}; | }; | |||
skipping to change at page 466, line 28 | skipping to change at page 468, line 6 | |||
The stateid argument for SETATTR is used to provide file locking | The stateid argument for SETATTR is used to provide file locking | |||
context that is necessary for SETATTR requests that set the size | context that is necessary for SETATTR requests that set the size | |||
attribute. Since setting the size attribute modifies the file's | attribute. Since setting the size attribute modifies the file's | |||
data, it has the same locking requirements as a corresponding WRITE. | data, it has the same locking requirements as a corresponding WRITE. | |||
Any SETATTR that sets the size attribute is incompatible with a share | Any SETATTR that sets the size attribute is incompatible with a share | |||
reservation that specifies DENY_WRITE. The area between the old end- | reservation that specifies DENY_WRITE. The area between the old end- | |||
of-file and the new end-of-file is considered to be modified just as | of-file and the new end-of-file is considered to be modified just as | |||
would have been the case had the area in question been specified as | would have been the case had the area in question been specified as | |||
the target of WRITE, for the purpose of checking conflicts with byte- | the target of WRITE, for the purpose of checking conflicts with byte- | |||
range locks, for those cases in which a server is implementing | range locks, for those cases in which a server is implementing | |||
mandatory byte-range locking behavior. A valid stateid should always | mandatory byte-range locking behavior. A valid stateid SHOULD always | |||
be specified. When the file size attribute is not set, the special | be specified. When the file size attribute is not set, the special | |||
stateid consisting of all bits zero should be passed. | stateid consisting of all bits zero MAY be passed. | |||
On either success or failure of the operation, the server will return | On either success or failure of the operation, the server will return | |||
the attrsset bitmask to represent what (if any) attributes were | the attrsset bitmask to represent what (if any) attributes were | |||
successfully set. The attrsset in the response is a subset of the | successfully set. The attrsset in the response is a subset of the | |||
bitmap4 that is part of the obj_attributes in the argument. | attrmask field of the obj_attributes field in the argument. | |||
On success, the current filehandle retains its value. | On success, the current filehandle retains its value. | |||
18.30.4. IMPLEMENTATION | 18.30.4. IMPLEMENTATION | |||
If the request specifies the owner attribute to be set, the server | If the request specifies the owner attribute to be set, the server | |||
should allow the operation to succeed if the current owner of the | SHOULD allow the operation to succeed if the current owner of the | |||
object matches the value specified in the request. Some servers may | object matches the value specified in the request. Some servers may | |||
be implemented in a way as to prohibit the setting of the owner | be implemented in a way as to prohibit the setting of the owner | |||
attribute unless the requester has privilege to do so. If the server | attribute unless the requester has privilege to do so. If the server | |||
is lenient in this one case of matching owner values, the client | is lenient in this one case of matching owner values, the client | |||
implementation may be simplified in cases of creation of an object | implementation may be simplified in cases of creation of an object | |||
followed by a SETATTR. | (e.g. an exclusive create via OPEN) followed by a SETATTR. | |||
The file size attribute is used to request changes to the size of a | The file size attribute is used to request changes to the size of a | |||
file. A value of 0 (zero) causes the file to be truncated, a value | file. A value of zero causes the file to be truncated, a value less | |||
less than the current size of the file causes data from new size to | than the current size of the file causes data from new size to the | |||
the end of the file to be discarded, and a size greater than the | end of the file to be discarded, and a size greater than the current | |||
current size of the file causes logically zeroed data bytes to be | size of the file causes logically zeroed data bytes to be added to | |||
added to the end of the file. Servers are free to implement this | the end of the file. Servers are free to implement this using | |||
using holes or actual zero data bytes. Clients should not make any | unallocate bytes (holes) or allocated data bytes set to zero. | |||
assumptions regarding a server's implementation of this feature, | Clients should not make any assumptions regarding a server's | |||
beyond that the bytes returned will be zeroed. Servers must support | implementation of this feature, beyond that the bytes in affected | |||
region returned by READ will be zeroed. Servers MUST support | ||||
extending the file size via SETATTR. | extending the file size via SETATTR. | |||
SETATTR is not guaranteed atomic. A failed SETATTR may partially | SETATTR is not guaranteed to be atomic. A failed SETATTR may | |||
change a file's attributes. | partially change a file's attributes, hence the reason why the reply | |||
always includes the status and the list of attributes that were set. | ||||
If the object whose attributes are being changed has a file | If the object whose attributes are being changed has a file | |||
delegation which is held by a client other than the one doing the | delegation which is held by a client other than the one doing the | |||
SETATTR, the delegation(s) must be recalled, and the operation cannot | SETATTR, the delegation(s) must be recalled, and the operation cannot | |||
proceed to actually change an attribute until each such delegation is | proceed to actually change an attribute until each such delegation is | |||
returned or revoked. In all cases in which delegations are recalled, | returned or revoked. In all cases in which delegations are recalled, | |||
the server is likely to return one or more NFS4ERR_DELAY error while | the server is likely to return one or more NFS4ERR_DELAY error while | |||
the delegation(s) remains outstanding, although it may, if the | the delegation(s) remains outstanding, although it may, if the | |||
returns happen quickly, not do that. | returns happen quickly, not do that. | |||
If the object whose attributes are being set is a directory and | If the object whose attributes are being set is a directory and | |||
another client holds a directory delegation for that directory, then | another client holds a directory delegation for that directory, then | |||
asynchronous notifications will be generated when the set of | if enabled, asynchronous notifications will be generated when the set | |||
attributes changed has a non-null intersection with the set of | of attributes changed has a non-null intersection with the set of | |||
attributes for which notification is requested. Notifications of | attributes for which notification is requested. Notifications of | |||
type NOTIFY4_CHANGE_DIR_ATTRS will be sent to the appropriate | type NOTIFY4_CHANGE_DIR_ATTRS will be sent to the appropriate | |||
client(s), but the SETATTR is not delayed by waiting for these | client(s), but the SETATTR is not delayed by waiting for these | |||
notifications to be sent. | notifications to be sent. | |||
If the object whose attributes are being set is a member of directory | If the object whose attributes are being set is a member of directory | |||
for which another client holds a directory delegation, then | for which another client holds a directory delegation, then | |||
asynchronous notifications will be generated when the set of | asynchronous notifications will be generated when the set of | |||
attributes changed has a non-null intersection with the set of | attributes changed has a non-null intersection with the set of | |||
attributes for which notification is requested. Notifications of | attributes for which notification is requested. Notifications of | |||
type NOTIFY4_CHANGE_CHILD_ATTRS will be sent to the appropriate | type NOTIFY4_CHANGE_CHILD_ATTRS will be sent to the appropriate | |||
client(s), but the SETATTR is not delayed by waiting for these | clients, but the SETATTR is not delayed by waiting for these | |||
notifications to be sent. | notifications to be sent. | |||
Changing the size of a file with SETATTR indirectly changes the | Changing the size of a file with SETATTR indirectly changes the | |||
time_modify. A client must account for this as size changes can | time_modify and change attributes. A client must account for this as | |||
result in data deletion. | size changes can result in data deletion. | |||
The attributes time_access_set and time_modify_set are write-only | The attributes time_access_set and time_modify_set are write-only | |||
attributes constructed as a switched union so the client can direct | attributes constructed as a switched union so the client can direct | |||
the server in setting the time values. If the switched union | the server in setting the time values. If the switched union | |||
specifies SET_TO_CLIENT_TIME4, the client has provided an nfstime4 to | specifies SET_TO_CLIENT_TIME4, the client has provided an nfstime4 to | |||
be used for the operation. If the switch union does not specify | be used for the operation. If the switch union does not specify | |||
SET_TO_CLIENT_TIME4, the server is to use its current time for the | SET_TO_CLIENT_TIME4, the server is to use its current time for the | |||
SETATTR operation. | SETATTR operation. | |||
If server and client times differ, programs that compare client time | If server and client times differ, programs that compare client time | |||
to file times can break. A time maintenance protocol should be used | to file times can break. A time synchronization protocol should be | |||
to limit client/server time skew. | used to limit client/server time skew. | |||
Use of a COMPOUND containing a VERIFY operation specifying only the | Use of a COMPOUND containing a VERIFY operation specifying only the | |||
change attribute, immediately followed by a SETATTR, provides a means | change attribute, immediately followed by a SETATTR, provides a means | |||
whereby a client may specify a request that emulates the | whereby a client may specify a request that emulates the | |||
functionality of the SETATTR guard mechanism of NFSv3. Since the | functionality of the SETATTR guard mechanism of NFSv3. Since the | |||
function of the guard mechanism is to avoid changes to the file | function of the guard mechanism is to avoid changes to the file | |||
attributes based on stale information, delays between checking of the | attributes based on stale information, delays between checking of the | |||
guard condition and the setting of the attributes have the potential | guard condition and the setting of the attributes have the potential | |||
to compromise this function, as would the corresponding delay in the | to compromise this function, as would the corresponding delay in the | |||
NFSv4 emulation. Therefore, NFSv4.1 servers should take care to | NFSv4 emulation. Therefore, NFSv4.1 servers SHOULD take care to | |||
avoid such delays, to the degree possible, when executing such a | avoid such delays, to the degree possible, when executing such a | |||
request. | request. | |||
If the server does not support an attribute as requested by the | If the server does not support an attribute as requested by the | |||
client, the server should return NFS4ERR_ATTRNOTSUPP. | client, the server SHOULD return NFS4ERR_ATTRNOTSUPP. | |||
A mask of the attributes actually set is returned by SETATTR in all | A mask of the attributes actually set is returned by SETATTR in all | |||
cases. That mask must not include attributes bits not requested to | cases. That mask MUST NOT include attributes bits not requested to | |||
be set by the client, and must be equal to the mask of attributes | be set by the client. If the attribute masks in the request and | |||
requested to be set only if the SETATTR completes without error. | reply are equal, the the status field in the reply MUST be NFS4_OK. | |||
18.31. Operation 37: VERIFY - Verify Same Attributes | 18.31. Operation 37: VERIFY - Verify Same Attributes | |||
18.31.1. ARGUMENTS | 18.31.1. ARGUMENTS | |||
struct VERIFY4args { | struct VERIFY4args { | |||
/* CURRENT_FH: object */ | /* CURRENT_FH: object */ | |||
fattr4 obj_attributes; | fattr4 obj_attributes; | |||
}; | }; | |||
18.31.2. RESULTS | 18.31.2. RESULTS | |||
struct VERIFY4res { | struct VERIFY4res { | |||
nfsstat4 status; | nfsstat4 status; | |||
}; | }; | |||
18.31.3. DESCRIPTION | 18.31.3. DESCRIPTION | |||
The VERIFY operation is used to verify that attributes have a value | The VERIFY operation is used to verify that attributes have the value | |||
assumed by the client before proceeding with following operations in | assumed by the client before proceeding with following operations in | |||
the compound request. If any of the attributes do not match then the | the COMPOUND request. If any of the attributes do not match then the | |||
error NFS4ERR_NOT_SAME must be returned. The current filehandle | error NFS4ERR_NOT_SAME must be returned. The current filehandle | |||
retains its value after successful completion of the operation. | retains its value after successful completion of the operation. | |||
18.31.4. IMPLEMENTATION | 18.31.4. IMPLEMENTATION | |||
One possible use of the VERIFY operation is the following compound | One possible use of the VERIFY operation is the following series of | |||
sequence. With this the client is attempting to verify that the file | operations. With this the client is attempting to verify that the | |||
being removed will match what the client expects to be removed. This | file being removed will match what the client expects to be removed. | |||
sequence can help prevent the unintended deletion of a file. | This series can help prevent the unintended deletion of a file. | |||
PUTFH (directory filehandle) | PUTFH (directory filehandle) | |||
LOOKUP (file name) | LOOKUP (file name) | |||
VERIFY (filehandle == fh) | VERIFY (filehandle == fh) | |||
PUTFH (directory filehandle) | PUTFH (directory filehandle) | |||
REMOVE (file name) | REMOVE (file name) | |||
This sequence does not prevent a second client from removing and | This series does not prevent a second client from removing and | |||
creating a new file in the middle of this sequence but it does help | creating a new file in the middle of this sequence but it does help | |||
avoid the unintended result. | avoid the unintended result. | |||
In the case that a RECOMMENDED attribute is specified in the VERIFY | In the case that a RECOMMENDED attribute is specified in the VERIFY | |||
operation and the server does not support that attribute for the file | operation and the server does not support that attribute for the file | |||
system object, the error NFS4ERR_ATTRNOTSUPP is returned to the | system object, the error NFS4ERR_ATTRNOTSUPP is returned to the | |||
client. | client. | |||
When the attribute rdattr_error or any write-only attribute (e.g. | When the attribute rdattr_error or any set-only attribute (e.g. | |||
time_modify_set) is specified, the error NFS4ERR_INVAL is returned to | time_modify_set) is specified, the error NFS4ERR_INVAL is returned to | |||
the client. | the client. | |||
18.32. Operation 38: WRITE - Write to File | 18.32. Operation 38: WRITE - Write to File | |||
18.32.1. ARGUMENTS | 18.32.1. ARGUMENTS | |||
enum stable_how4 { | enum stable_how4 { | |||
UNSTABLE4 = 0, | UNSTABLE4 = 0, | |||
DATA_SYNC4 = 1, | DATA_SYNC4 = 1, | |||
skipping to change at page 470, line 45 | skipping to change at page 472, line 8 | |||
18.32.3. DESCRIPTION | 18.32.3. DESCRIPTION | |||
The WRITE operation is used to write data to a regular file. The | The WRITE operation is used to write data to a regular file. The | |||
target file is specified by the current filehandle. The offset | target file is specified by the current filehandle. The offset | |||
specifies the offset where the data should be written. An offset of | specifies the offset where the data should be written. An offset of | |||
0 (zero) specifies that the write should start at the beginning of | 0 (zero) specifies that the write should start at the beginning of | |||
the file. The count, as encoded as part of the opaque data | the file. The count, as encoded as part of the opaque data | |||
parameter, represents the number of bytes of data that are to be | parameter, represents the number of bytes of data that are to be | |||
written. If the count is 0 (zero), the WRITE will succeed and return | written. If the count is 0 (zero), the WRITE will succeed and return | |||
a count of 0 (zero) subject to permissions checking. The server may | a count of 0 (zero) subject to permissions checking. The server MAY | |||
choose to write fewer bytes than requested by the client. | write fewer bytes than requested by the client. | |||
Part of the write request is a specification of how the write is to | The client specifies with the stable parameter the method of how the | |||
be performed. The client specifies with the stable parameter the | data is to be processed by the server. If stable is FILE_SYNC4, the | |||
method of how the data is to be processed by the server. If stable | server MUST commit the data written plus all file system metadata to | |||
is FILE_SYNC4, the server must commit the data written plus all file | stable storage before returning results. This corresponds to the | |||
system metadata to stable storage before returning results. This | NFSv2 protocol semantics. Any other behavior constitutes a protocol | |||
corresponds to the NFSv2 protocol semantics. Any other behavior | violation. If stable is DATA_SYNC4, then the server MUST commit all | |||
constitutes a protocol violation. If stable is DATA_SYNC4, then the | of the data to stable storage and enough of the metadata to retrieve | |||
server must commit all of the data to stable storage and enough of | the data before returning. The server implementor is free to | |||
the metadata to retrieve the data before returning. The server | implement DATA_SYNC4 in the same fashion as FILE_SYNC4, but with a | |||
implementor is free to implement DATA_SYNC4 in the same fashion as | possible performance drop. If stable is UNSTABLE4, the server is | |||
FILE_SYNC4, but with a possible performance drop. If stable is | free to commit any part of the data and the metadata to stable | |||
UNSTABLE4, the server is free to commit any part of the data and the | storage, including all or none, before returning a reply to the | |||
metadata to stable storage, including all or none, before returning a | client. There is no guarantee whether or when any uncommitted data | |||
reply to the client. There is no guarantee whether or when any | will subsequently be committed to stable storage. The only | |||
uncommitted data will subsequently be committed to stable storage. | guarantees made by the server are that it will not destroy any data | |||
The only guarantees made by the server are that it will not destroy | without changing the value of writeverf and that it will not commit | |||
any data without changing the value of verf and that it will not | the data and metadata at a level less than that requested by the | |||
commit the data and metadata at a level less than that requested by | client. | |||
the client. | ||||
Except when special stateids are used, the stateid value for a WRITE | Except when special stateids are used, the stateid value for a WRITE | |||
request represents a value returned from a previous byte-range lock | request represents a value returned from a previous byte-range LOCK | |||
or share reservation request or the stateid associated with a | or OPEN request or the stateid associated with a delegation. The | |||
delegation. The stateid identifies the associated owners if any and | stateid identifies the associated owners if any and is used by the | |||
is used by the server to verify that the associated locks are still | server to verify that the associated locks are still valid (e.g. have | |||
valid (e.g. have not been revoked). | not been revoked). | |||
Upon successful completion, the following results are returned. The | Upon successful completion, the following results are returned. The | |||
count result is the number of bytes of data written to the file. The | count result is the number of bytes of data written to the file. The | |||
server may write fewer bytes than requested. If so, the actual | server may write fewer bytes than requested. If so, the actual | |||
number of bytes written starting at location, offset, is returned. | number of bytes written starting at location, offset, is returned. | |||
The server also returns an indication of the level of commitment of | The server also returns an indication of the level of commitment of | |||
the data and metadata via committed. If the server committed all | the data and metadata via committed. Per Table 20, | |||
data and metadata to stable storage, committed should be set to | ||||
FILE_SYNC4. If the level of commitment was at least as strong as | ||||
DATA_SYNC4, then committed should be set to DATA_SYNC4. Otherwise, | ||||
committed must be returned as UNSTABLE4. If stable was FILE4_SYNC, | ||||
then committed must also be FILE_SYNC4: anything else constitutes a | ||||
protocol violation. If stable was DATA_SYNC4, then committed may be | ||||
FILE_SYNC4 or DATA_SYNC4: anything else constitutes a protocol | ||||
violation. If stable was UNSTABLE4, then committed may be either | ||||
FILE_SYNC4, DATA_SYNC4, or UNSTABLE4. | ||||
The final portion of the result is the write verifier. The write | o The server MAY commit the data at a stronger level than requested. | |||
verifier is a cookie that the client can use to determine whether the | ||||
server has changed instance (boot) state between a call to WRITE and | o The server MUST commit the data at a level at least as high as | |||
a subsequent call to either WRITE or COMMIT. This cookie must be | that committed. | |||
consistent during a single instance of the NFSv4.1 protocol service | ||||
and must be unique between instances of the NFSv4.1 protocol server, | Valid combinations of the stable in the request and committed in the | |||
where uncommitted data may be lost. | reply. | |||
+------------+-----------------------------------+ | ||||
| stable | committed | | ||||
+------------+-----------------------------------+ | ||||
| UNSTABLE4 | FILE_SYNC4, DATA_SYNC4, UNSTABLE4 | | ||||
| DATA_SYNC4 | FILE_SYNC4, DATA_SYNC4 | | ||||
| FILE_SYNC4 | FILE_SYNC4 | | ||||
+------------+-----------------------------------+ | ||||
Table 20 | ||||
The final portion of the result is the field writeverf. This field | ||||
is the write verifier and is a cookie that the client can use to | ||||
determine whether a server has changed instance state (e.g. server | ||||
restart) between a call to WRITE and a subsequent call to either | ||||
WRITE or COMMIT. This cookie MUST be unchanged during a single | ||||
instance of the NFSv4.1 server and MUST be unique between instances | ||||
of the NFSv4.1 server. If the cookie changes, then the client MUST | ||||
assume that any data written with an UNSTABLE4 value for committed | ||||
and an old writeverf in the reply has been lost and will need to be | ||||
recovered. | ||||
If a client writes data to the server with the stable argument set to | If a client writes data to the server with the stable argument set to | |||
UNSTABLE4 and the reply yields a committed response of DATA_SYNC4 or | UNSTABLE4 and the reply yields a committed response of DATA_SYNC4 or | |||
UNSTABLE4, the client will follow up some time in the future with a | UNSTABLE4, the client will follow up some time in the future with a | |||
COMMIT operation to synchronize outstanding asynchronous data and | COMMIT operation to synchronize outstanding asynchronous data and | |||
metadata with the server's stable storage, barring client error. It | metadata with the server's stable storage, barring client error. It | |||
is possible that due to client crash or other error that a subsequent | is possible that due to client crash or other error that a subsequent | |||
COMMIT will not be received by the server. | COMMIT will not be received by the server. | |||
For a WRITE with a stateid value of all bits 0, the server MAY allow | For a WRITE with a stateid value of all bits 0, the server MAY allow | |||
the WRITE to be serviced subject to mandatory file locks or the | the WRITE to be serviced subject to mandatory file locks or the | |||
current share deny modes for the file. For a WRITE with a stateid | current share deny modes for the file. For a WRITE with a stateid | |||
value of all bits 1, the server MUST NOT allow the WRITE operation to | value of all bits 1, the server MUST NOT allow the WRITE operation to | |||
bypass locking checks at the server and are treated exactly the same | bypass locking checks at the server and otherwise is treated as if a | |||
as if a stateid of all bits 0 were used. | stateid of all bits 0 were used. | |||
On success, the current filehandle retains its value. | On success, the current filehandle retains its value. | |||
18.32.4. IMPLEMENTATION | 18.32.4. IMPLEMENTATION | |||
It is possible for the server to write fewer bytes of data than | It is possible for the server to write fewer bytes of data than | |||
requested by the client. In this case, the server should not return | requested by the client. In this case, the server SHOULD NOT return | |||
an error unless no data was written at all. If the server writes | an error unless no data was written at all. If the server writes | |||
less than the number of bytes specified, the client should send | less than the number of bytes specified, the client will need to send | |||
another WRITE to write the remaining data. | another WRITE to write the remaining data. | |||
It is assumed that the act of writing data to a file will cause the | It is assumed that the act of writing data to a file will cause the | |||
time_modified of the file to be updated. However, the time_modified | time_modified and change attributes of the file to be updated. | |||
of the file should not be changed unless the contents of the file are | However, these attributes SHOULD NOT be changed unless the contents | |||
changed. Thus, a WRITE request with count set to 0 should not cause | of the file are changed. Thus, a WRITE request with count set to 0 | |||
the time_modified of the file to be updated. | SHOULD NOT cause the time_modified and change attributes of the file | |||
to be updated. | ||||
The definition of stable storage has been historically a point of | Stable storage is persistent storage that survives: | |||
contention. The following expected properties of stable storage may | ||||
help in resolving design sends in the implementation. Stable storage | ||||
is persistent storage that survives: | ||||
1. Repeated power failures. | 1. Repeated power failures. | |||
2. Hardware failures (of any board, power supply, etc.). | 2. Hardware failures (of any board, power supply, etc.). | |||
3. Repeated software crashes and restarts. | 3. Repeated software crashes and restarts. | |||
This definition does not address failure of the stable storage module | This definition does not address failure of the stable storage module | |||
itself. | itself. | |||
The verifier is defined to allow a client to detect different | The verifier is defined to allow a client to detect different | |||
instances of an NFSv4.1 protocol server over which cached, | instances of an NFSv4.1 protocol server over which cached, | |||
uncommitted data may be lost. In the most likely case, the verifier | uncommitted data may be lost. In the most likely case, the verifier | |||
allows the client to detect server restarts. This information is | allows the client to detect server restarts. This information is | |||
required so that the client can safely determine whether the server | required so that the client can safely determine whether the server | |||
could have lost cached data. If the server fails unexpectedly and | could have lost cached data. If the server fails unexpectedly and | |||
the client has uncommitted data from previous WRITE requests (done | the client has uncommitted data from previous WRITE requests (done | |||
with the stable argument set to UNSTABLE4 and in which the result | with the stable argument set to UNSTABLE4 and in which the result | |||
committed was returned as UNSTABLE4 as well) it may not have flushed | committed was returned as UNSTABLE4 as well) the server might not | |||
cached data to stable storage. The burden of recovery is on the | have flushed cached data to stable storage. The burden of recovery | |||
client and the client will need to retransmit the data to the server. | is on the client and the client will need to retransmit the data to | |||
the server. | ||||
A suggested verifier would be to use the time that the server was | A suggested verifier would be to use the time that the server was | |||
last started (if restarting the server results in lost buffers). | last started (if restarting the server results in lost buffers). | |||
The committed field in the results allows the client to do more | The reply's committed field allows the client to do more effective | |||
effective caching. If the server is committing all WRITE requests to | caching. If the server is committing all WRITE requests to stable | |||
stable storage, then it should return with committed set to | storage, then it SHOULD return with committed set to FILE_SYNC4, | |||
FILE_SYNC4, regardless of the value of the stable field in the | regardless of the value of the stable field in the arguments. A | |||
arguments. A server that uses an NVRAM accelerator may choose to | server that uses an NVRAM accelerator may choose to implement this | |||
implement this policy. The client can use this to increase the | policy. The client can use this to increase the effectiveness of the | |||
effectiveness of the cache by discarding cached data that has already | cache by discarding cached data that has already been committed on | |||
been committed on the server. | the server. | |||
Some implementations may return NFS4ERR_NOSPC instead of | Some implementations may return NFS4ERR_NOSPC instead of | |||
NFS4ERR_DQUOT when a user's quota is exceeded. In the case that the | NFS4ERR_DQUOT when a user's quota is exceeded. | |||
current filehandle is of type NF4DIR, the server will return | ||||
NFS4ERR_ISDIR. If the current file is a symbolic link, the error | ||||
NFS4ERR_SYMLINK will be returned. Otherwise, if the current | ||||
filehandle does not designate an ordinary file, the server will | ||||
return NFS4ERR_WRONG_TYPE. | ||||
If mandatory file locking is on for the file, and corresponding byte- | In the case that the current filehandle is of type NF4DIR, the server | |||
range of the data to be written file is read or write locked by an | will return NFS4ERR_ISDIR. If the current file is a symbolic link, | |||
owner that is not associated with the stateid, the server will return | the error NFS4ERR_SYMLINK will be returned. Otherwise, if the | |||
NFS4ERR_LOCKED. If so, the client must check if the owner | current filehandle does not designate an ordinary file, the server | |||
corresponding to the stateid used with the WRITE operation has a | will return NFS4ERR_WRONG_TYPE. | |||
conflicting read lock that overlaps with the region that was to be | ||||
written. If the stateid's owner has no conflicting read lock, then | If mandatory file locking is effect for the file, and the | |||
the client should try to get the appropriate write byte-range lock | corresponding byte-range of the data to be written to the file is | |||
via the LOCK operation before re-attempting the WRITE. When the | read or write locked by an owner that is not associated with the | |||
WRITE completes, the client should release the byte-range lock via | stateid, the server MUST return NFS4ERR_LOCKED. If so, the client | |||
LOCKU. | MUST check if the owner corresponding to the stateid used with the | |||
WRITE operation has a conflicting read lock that overlaps with the | ||||
region that was to be written. If the stateid's owner has no | ||||
conflicting read lock, then the client SHOULD try to get the | ||||
appropriate write byte-range lock via the LOCK operation before re- | ||||
attempting the WRITE. When the WRITE completes, the client SHOULD | ||||
release the byte-range lock via LOCKU. | ||||
If the stateid's owner had a conflicting read lock, then the client | If the stateid's owner had a conflicting read lock, then the client | |||
has no choice but to return an error to the application that | has no choice but to return an error to the application that | |||
attempted the WRITE. The reason is that since the stateid's owner | attempted the WRITE. The reason is that since the stateid's owner | |||
had a read lock, the server either attempted to temporarily | had a read lock, the server either attempted to temporarily | |||
effectively upgrade this read lock to a write lock, or the server has | effectively upgrade this read lock to a write lock, or the server has | |||
no upgrade capability. If the server attempted to upgrade the read | no upgrade capability. If the server attempted to upgrade the read | |||
lock and failed, it is pointless for the client to re-attempt the | lock and failed, it is pointless for the client to re-attempt the | |||
upgrade via the LOCK operation, because there might be another client | upgrade via the LOCK operation, because there might be another client | |||
also trying to upgrade. If two clients are blocked trying upgrade | also trying to upgrade. If two clients are blocked trying upgrade | |||
the same lock, the clients deadlock. If the server has no upgrade | the same lock, the clients deadlock. If the server has no upgrade | |||
capability, then it is pointless to try a LOCK operation to upgrade. | capability, then it is pointless to try a LOCK operation to upgrade. | |||
If one or more other clients have delegations for the file being | If one or more other clients have delegations for the file being | |||
written, those delegations must be recalled, and the operation cannot | written, those delegations MUST be recalled, and the operation cannot | |||
proceed until those delegations are returned or revoked. Except | proceed until those delegations are returned or revoked. Except | |||
where this happens very quickly, one or more NFS4ERR_DELAY errors | where this happens very quickly, one or more NFS4ERR_DELAY errors | |||
will be returned to requests made while the delegation remains | will be returned to requests made while the delegation remains | |||
outstanding. Normally, delegations will not be recalled as a result | outstanding. Normally, delegations will not be recalled as a result | |||
of a WRITE operation since the recall will occur as a result of an | of a WRITE operation since the recall will occur as a result of an | |||
earlier OPEN. However, since it is possible for a WRITE to be done | earlier OPEN. However, since it is possible for a WRITE to be done | |||
with a special stateid, the server needs to check for this case even | with a special stateid, the server needs to check for this case even | |||
though the client should have done an OPEN previously. | though the client should have done an OPEN previously. | |||
18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control | 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control | |||
skipping to change at page 504, line 44 | skipping to change at page 505, line 44 | |||
be incremented. | be incremented. | |||
o Adding a function to create a new RPCSEC_GSS handle from a pointer | o Adding a function to create a new RPCSEC_GSS handle from a pointer | |||
to the wrapper data structure. The reference count would be | to the wrapper data structure. The reference count would be | |||
incremented. | incremented. | |||
o Replacing calls from RPCSEC_GSS that free GSS-API contexts, with | o Replacing calls from RPCSEC_GSS that free GSS-API contexts, with | |||
calls to decrement the reference count on the wrapper data | calls to decrement the reference count on the wrapper data | |||
structure. | structure. | |||
If the server cannot reserve space for the reply cache, it MAY return | ||||
NFS4ERR_NOSPC. | ||||
18.37. Operation 44: DESTROY_SESSION - Destroy existing session | 18.37. Operation 44: DESTROY_SESSION - Destroy existing session | |||
Destroy existing session. | Destroy existing session. | |||
18.37.1. ARGUMENT | 18.37.1. ARGUMENT | |||
struct DESTROY_SESSION4args { | struct DESTROY_SESSION4args { | |||
sessionid4 dsa_sessionid; | sessionid4 dsa_sessionid; | |||
}; | }; | |||
skipping to change at page 527, line 39 | skipping to change at page 528, line 39 | |||
18.45.2. RESULT | 18.45.2. RESULT | |||
/* CURRENTFH: consumed if status is NFS4_OK */ | /* CURRENTFH: consumed if status is NFS4_OK */ | |||
typedef SECINFO4res SECINFO_NO_NAME4res; | typedef SECINFO4res SECINFO_NO_NAME4res; | |||
18.45.3. DESCRIPTION | 18.45.3. DESCRIPTION | |||
Like the SECINFO operation, SECINFO_NO_NAME is used by the client to | Like the SECINFO operation, SECINFO_NO_NAME is used by the client to | |||
obtain a list of valid RPC authentication flavors for a specific file | obtain a list of valid RPC authentication flavors for a specific file | |||
object. Unlike SECINFO, SECINFO_NO_NAME only works with objects are | object. Unlike SECINFO, SECINFO_NO_NAME only works with objects that | |||
accessed by filehandle. | are accessed by filehandle. | |||
There are two styles of SECINFO_NO_NAME, as determined by the value | There are two styles of SECINFO_NO_NAME, as determined by the value | |||
of the secinfo_style4 enumeration. If SECINFO_STYLE4_CURRENT_FH is | of the secinfo_style4 enumeration. If SECINFO_STYLE4_CURRENT_FH is | |||
passed, then SECINFO_NO_NAME is querying for the required security | passed, then SECINFO_NO_NAME is querying for the required security | |||
for the current filehandle. If SECINFO_STYLE4_PARENT is passed, then | for the current filehandle. If SECINFO_STYLE4_PARENT is passed, then | |||
SECINFO_NO_NAME is querying for the required security of the current | SECINFO_NO_NAME is querying for the required security of the current | |||
filehandles's parent. If the style selected is | filehandle's parent. If the style selected is SECINFO_STYLE4_PARENT, | |||
SECINFO_STYLE4_PARENT, then SECINFO should apply the same access | then SECINFO should apply the same access methodology used for | |||
methodology used for LOOKUPP when evaluating the traversal to the | LOOKUPP when evaluating the traversal to the parent directory. | |||
parent directory. Therefore, if the requester does not have the | ||||
appropriate access to LOOKUPP the parent then SECINFO_NO_NAME must | ||||
behave the same way and return NFS4ERR_ACCESS. | ||||
Note that if PUTFH, PUTPUBFH, or PUTROOTFH return NFS4ERR_WRONGSEC, | Therefore, if the requester does not have the appropriate access to | |||
this is tantamount to the server asserting that the client will have | LOOKUPP the parent then SECINFO_NO_NAME must behave the same way and | |||
to guess what the required security is, because there is no way to | return NFS4ERR_ACCESS. | |||
query. Therefore, the client must iterate through the security | ||||
triples available at the client and reattempt the PUTFH, PUTROOTFH or | ||||
PUTPUBFH operation. In the unfortunate event none of the REQUIRED | ||||
security triples are supported by the client and server, the client | ||||
SHOULD try using others that support integrity. Failing that, the | ||||
client can try using other forms (e.g. AUTH_SYS and AUTH_NONE), but | ||||
because such forms lack integrity checks, this puts the client at | ||||
risk. | ||||
The server implementor should pay particular attention to Section 2.6 | If PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH return NFS4ERR_WRONGSEC, | |||
for instructions on avoiding NFS4ERR_WRONGSEC error returns from | then the client resolves the situation by sending a COMPOUND request | |||
that consists of PUTFH, PUTPUBFH, or PUTROOTFH immediately followed | ||||
by SECINFO_NO_NAME, style SECINFO_STYLE4_CURRENT_FH. See Section 2.6 | ||||
for instructions on dealing with NFS4ERR_WRONGSEC error returns from | ||||
PUTFH, PUTROOTFH, PUTPUBFH, or RESTOREFH. | PUTFH, PUTROOTFH, PUTPUBFH, or RESTOREFH. | |||
If SECINFO_STYLE4_PARENT is specified and there is no parent | If SECINFO_STYLE4_PARENT is specified and there is no parent | |||
directory, SECINFO_NO_NAME MUST return NFS4ERR_NOENT. | directory, SECINFO_NO_NAME MUST return NFS4ERR_NOENT. | |||
On success, the current filehandle is consumed (see | On success, the current filehandle is consumed (see | |||
Section 2.6.3.1.8), and if the next operation after SECINFO_NO_NAME | Section 2.6.3.1.1.8), and if the next operation after SECINFO_NO_NAME | |||
tries to use the current filehandle, that operation will fail with | tries to use the current filehandle, that operation will fail with | |||
the status NFS4ERR_NOFILEHANDLE. | the status NFS4ERR_NOFILEHANDLE. | |||
Everything else about SECINFO_NO_NAME is the same as SECINFO. See | Everything else about SECINFO_NO_NAME is the same as SECINFO. See | |||
the discussion on SECINFO (Section 18.29.3). | the discussion on SECINFO (Section 18.29.3). | |||
18.45.4. IMPLEMENTATION | 18.45.4. IMPLEMENTATION | |||
See the discussion on SECINFO (Section 18.29.4). | See the discussion on SECINFO (Section 18.29.4). | |||
skipping to change at page 550, line 28 | skipping to change at page 550, line 28 | |||
| NFS4ERR_INVAL | The tag argument is not in UTF-8 | | | NFS4ERR_INVAL | The tag argument is not in UTF-8 | | |||
| | encoding. | | | | encoding. | | |||
| NFS4ERR_MINOR_VERS_MISMATCH | | | | NFS4ERR_MINOR_VERS_MISMATCH | | | |||
| NFS4ERR_SERVERFAULT | | | | NFS4ERR_SERVERFAULT | | | |||
| NFS4ERR_TOO_MANY_OPS | | | | NFS4ERR_TOO_MANY_OPS | | | |||
| NFS4ERR_REP_TOO_BIG | | | | NFS4ERR_REP_TOO_BIG | | | |||
| NFS4ERR_REP_TOO_BIG_TO_CACHE | | | | NFS4ERR_REP_TOO_BIG_TO_CACHE | | | |||
| NFS4ERR_REQ_TOO_BIG | | | | NFS4ERR_REQ_TOO_BIG | | | |||
+------------------------------+------------------------------------+ | +------------------------------+------------------------------------+ | |||
Table 20 | Table 21 | |||
20. NFSv4.1 Callback Operations | 20. NFSv4.1 Callback Operations | |||
20.1. Operation 3: CB_GETATTR - Get Attributes | 20.1. Operation 3: CB_GETATTR - Get Attributes | |||
20.1.1. ARGUMENT | 20.1.1. ARGUMENT | |||
struct CB_GETATTR4args { | struct CB_GETATTR4args { | |||
nfs_fh4 fh; | nfs_fh4 fh; | |||
bitmap4 attr_request; | bitmap4 attr_request; | |||
End of changes. 112 change blocks. | ||||
638 lines changed or deleted | 723 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |