Found wdiff, but it reported no recognisable version. Falling back to builtin diff colouring... Diff: draft-pre-retention.txt - draft-ietf-nfsv4-minorversion1-22.txt
 draft-pre-retention.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 9, 2008 Editors Expires: October 10, 2008 Editors
April 7, 2008 April 8, 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 9, 2008. This Internet-Draft will expire on October 10, 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 3, line 45 skipping to change at page 3, line 45
5.7. Attribute Definitions . . . . . . . . . . . . . . . . . 102 5.7. Attribute Definitions . . . . . . . . . . . . . . . . . 102
5.7.1. Definitions of REQUIRED Attributes . . . . . . . . . 102 5.7.1. Definitions of REQUIRED Attributes . . . . . . . . . 102
5.7.2. Definitions of Uncategorized RECOMMENDED 5.7.2. Definitions of Uncategorized RECOMMENDED
Attributes . . . . . . . . . . . . . . . . . . . . . 104 Attributes . . . . . . . . . . . . . . . . . . . . . 104
5.8. Interpreting owner and owner_group . . . . . . . . . . . 110 5.8. Interpreting owner and owner_group . . . . . . . . . . . 110
5.9. Character Case Attributes . . . . . . . . . . . . . . . 112 5.9. Character Case Attributes . . . . . . . . . . . . . . . 112
5.10. Directory Notification Attributes . . . . . . . . . . . 112 5.10. Directory Notification Attributes . . . . . . . . . . . 112
5.11. pNFS Attribute Definitions . . . . . . . . . . . . . . . 113 5.11. pNFS Attribute Definitions . . . . . . . . . . . . . . . 113
5.12. Retention Attributes . . . . . . . . . . . . . . . . . . 115 5.12. Retention Attributes . . . . . . . . . . . . . . . . . . 115
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 117 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 117
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 118 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 119
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 118 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 119
6.2.2. Attribute 58: dacl . . . . . . . . . . . . . . . . . 133 6.2.2. Attribute 58: dacl . . . . . . . . . . . . . . . . . 134
6.2.3. Attribute 59: sacl . . . . . . . . . . . . . . . . . 133 6.2.3. Attribute 59: sacl . . . . . . . . . . . . . . . . . 134
6.2.4. Attribute 33: mode . . . . . . . . . . . . . . . . . 133 6.2.4. Attribute 33: mode . . . . . . . . . . . . . . . . . 134
6.2.5. Attribute 74: mode_set_masked . . . . . . . . . . . 134 6.2.5. Attribute 74: mode_set_masked . . . . . . . . . . . 134
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 135 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 135
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 135 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 135
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 136 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 136
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 137 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 137
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 137 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 138
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 139 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 139
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 139 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 140
7. Single-server Namespace . . . . . . . . . . . . . . . . . . . 143 7. Single-server Namespace . . . . . . . . . . . . . . . . . . . 143
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 143 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 144
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 144 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 144
7.3. Server Pseudo File System . . . . . . . . . . . . . . . 144 7.3. Server Pseudo File System . . . . . . . . . . . . . . . 145
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 145 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 145
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 145 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 145
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 145 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 146
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 146 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 146
7.8. Security Policy and Namespace Presentation . . . . . . . 146 7.8. Security Policy and Namespace Presentation . . . . . . . 147
8. State Management . . . . . . . . . . . . . . . . . . . . . . 147 8. State Management . . . . . . . . . . . . . . . . . . . . . . 148
8.1. Client and Session ID . . . . . . . . . . . . . . . . . 148 8.1. Client and Session ID . . . . . . . . . . . . . . . . . 148
8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 148 8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 149
8.2.1. Stateid Types . . . . . . . . . . . . . . . . . . . 149 8.2.1. Stateid Types . . . . . . . . . . . . . . . . . . . 149
8.2.2. Stateid Structure . . . . . . . . . . . . . . . . . 150 8.2.2. Stateid Structure . . . . . . . . . . . . . . . . . 150
8.2.3. Special Stateids . . . . . . . . . . . . . . . . . . 151 8.2.3. Special Stateids . . . . . . . . . . . . . . . . . . 152
8.2.4. Stateid Lifetime and Validation . . . . . . . . . . 153 8.2.4. Stateid Lifetime and Validation . . . . . . . . . . 153
8.2.5. Stateid Use for I/O Operations . . . . . . . . . . . 156 8.2.5. Stateid Use for I/O Operations . . . . . . . . . . . 156
8.2.6. Stateid Use for SETATTR Operations . . . . . . . . . 157 8.2.6. Stateid Use for SETATTR Operations . . . . . . . . . 157
8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 157 8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 157
8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 159 8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 160
8.4.1. Client Failure and Recovery . . . . . . . . . . . . 160 8.4.1. Client Failure and Recovery . . . . . . . . . . . . 160
8.4.2. Server Failure and Recovery . . . . . . . . . . . . 160 8.4.2. Server Failure and Recovery . . . . . . . . . . . . 161
8.4.3. Network Partitions and Recovery . . . . . . . . . . 164 8.4.3. Network Partitions and Recovery . . . . . . . . . . 165
8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 169 8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 169
8.6. Short and Long Leases . . . . . . . . . . . . . . . . . 170 8.6. Short and Long Leases . . . . . . . . . . . . . . . . . 170
8.7. Clocks, Propagation Delay, and Calculating Lease 8.7. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 170 Expiration . . . . . . . . . . . . . . . . . . . . . . . 171
8.8. Obsolete Locking Infrastructure From NFSv4.0 . . . . . . 171 8.8. Obsolete Locking Infrastructure From NFSv4.0 . . . . . . 171
9. File Locking and Share Reservations . . . . . . . . . . . . . 172 9. File Locking and Share Reservations . . . . . . . . . . . . . 172
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 172 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 172
9.1.1. State-owner Definition . . . . . . . . . . . . . . . 172 9.1.1. State-owner Definition . . . . . . . . . . . . . . . 173
9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 173 9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 173
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 176 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 176
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 176 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 177
9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 177 9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 177
9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 177 9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 177
9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 178 9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 178
9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 179 9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 179
9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 179 9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 180
9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 180 9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 180
9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 181 9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 181
9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 182 9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 182
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 182 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 182
10.1. Performance Challenges for Client-Side Caching . . . . . 183 10.1. Performance Challenges for Client-Side Caching . . . . . 183
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 184 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 184
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 186 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 186
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 188 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 188
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 188 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 189
10.3.2. Data Caching and File Locking . . . . . . . . . . . 189 10.3.2. Data Caching and File Locking . . . . . . . . . . . 190
10.3.3. Data Caching and Mandatory File Locking . . . . . . 191 10.3.3. Data Caching and Mandatory File Locking . . . . . . 191
10.3.4. Data Caching and File Identity . . . . . . . . . . . 191 10.3.4. Data Caching and File Identity . . . . . . . . . . . 192
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 193 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 193
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 195 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 195
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 196 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 196
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 197 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 197
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 200 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 200
10.4.5. Clients that Fail to Honor Delegation Recalls . . . 202 10.4.5. Clients that Fail to Honor Delegation Recalls . . . 202
10.4.6. Delegation Revocation . . . . . . . . . . . . . . . 202 10.4.6. Delegation Revocation . . . . . . . . . . . . . . . 202
10.4.7. Delegations via WANT_DELEGATION . . . . . . . . . . 203 10.4.7. Delegations via WANT_DELEGATION . . . . . . . . . . 203
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 204 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 204
10.5.1. Revocation Recovery for Write Open Delegation . . . 204 10.5.1. Revocation Recovery for Write Open Delegation . . . 204
skipping to change at page 115, line 18 skipping to change at page 115, line 18
5.12. Retention Attributes 5.12. Retention Attributes
Retention is a concept whereby a file object can be placed in an Retention is a concept whereby a file object can be placed in an
immutable, undeletable, unrenamable state for a fixed or infinite immutable, undeletable, unrenamable state for a fixed or infinite
duration of time. Once in this "retained" state, the file cannot be duration of time. Once in this "retained" state, the file cannot be
moved out of the state until the duration of retention has been moved out of the state until the duration of retention has been
reached. reached.
When retention is enabled, retention MUST extend to the data of the When retention is enabled, retention MUST extend to the data of the
file, and the name of file. The server MAY extend retention any file, and the name of file. The server MAY extend retention to any
other property of the file, including any subset of REQUIRED, other property of the file, including any subset of REQUIRED,
RECOMMENDED, and named attributes, with the exceptions noted in this RECOMMENDED, and named attributes, with the exceptions noted in this
section. section.
Servers MAY support or not support retention on any file object type. Servers MAY support or not support retention on any file object type.
The five retention attributes are explained in the next subsections. The five retention attributes are explained in the next subsections.
5.12.1. Attribute 69: retention_get 5.12.1. Attribute 69: retention_get
skipping to change at page 116, line 5 skipping to change at page 115, line 49
}; };
The field rg_duration is the duration in seconds indicating how long The field rg_duration is the duration in seconds indicating how long
the file will be retained once retention is enabled. The field the file will be retained once retention is enabled. The field
rg_begin_time is an array of up to one absolute time value. If the rg_begin_time is an array of up to one absolute time value. If the
array is zero length, no beginning retention time has been array is zero length, no beginning retention time has been
established, and retention is not enabled. If rg_duration is equal established, and retention is not enabled. If rg_duration is equal
to RET4_DURATION_INFINITE, the file, once retention is enabled, will to RET4_DURATION_INFINITE, the file, once retention is enabled, will
be retained for an infinite duration. be retained for an infinite duration.
If (as soon as) rg_duration is zero, then rg_begin_time will be of
zero length, and again, retention is not (no longer) enabled.
5.12.2. Attribute 70: retention_set 5.12.2. Attribute 70: retention_set
This attribute is used to set the retention duration and optionally This attribute is used to set the retention duration and optionally
enable retention for the associated file object. This attribute is enable retention for the associated file object. This attribute is
only modifiable via SETATTR operation and may not be read with the only modifiable via the SETATTR operation and may not be read with
GETATTR operation. This attribute corresponds to retention_get. The the GETATTR operation. This attribute corresponds to retention_get.
value of the attribute consists of: The value of the attribute consists of:
struct retention_set4 { struct retention_set4 {
bool rs_enable; bool rs_enable;
uint64_t rs_duration<1>; uint64_t rs_duration<1>;
}; };
If the client sets rs_enable to TRUE, then it is enabling retention If the client sets rs_enable to TRUE, then it is enabling retention
on the file object with the begin time of retention starting from the on the file object with the begin time of retention starting from the
server's current time and date. The duration of the retention can server's current time and date. The duration of the retention can
also be provided if the rs_duration array is of length one. The also be provided if the rs_duration array is of length one. The
duration is time in seconds from the begin time of retention, and if duration is the time in seconds from the begin time of retention, and
set to RET4_DURATION_INFINITE, the file is to be retained forever. if set to RET4_DURATION_INFINITE, the file is to be retained forever.
If retention is enabled, with no duration specified in either this If retention is enabled, with no duration specified in either this
SETATTR or a previous SETATTR, the duration defaults to zero seconds. SETATTR or a previous SETATTR, the duration defaults to zero seconds.
The server MAY restrict the enabling of retention or the duration of The server MAY restrict the enabling of retention or the duration of
retention on the basis of the ACE4_WRITE_RETENTION ACL permission. retention on the basis of the ACE4_WRITE_RETENTION ACL permission.
The enabling of retention does not prevent the enabling of event- The enabling of retention MUST NOT prevent the enabling of event-
based retention nor the modification of the retention_hold attribute. based retention nor the modification of the retention_hold attribute.
The following rules apply to both the retention_set and retentevt_set
attributes.
o As long as retention is not enabled, the client is permitted to
decrease the duration.
o The duration can always be set to an equal or higher value, even
if retention is enabled. Note that once retention is enabled, the
actual duration (as returned by the retention_get or retentevt_get
attributes, see Section 5.12.1 or Section 5.12.3), is constantly
counting down to zero (one unit per second), unless the duration
was set to RET4_DURATION_INFINITE. Thus it will not be possible
for the client to precisely extend the duration on a file that has
retention enabled.
o While retention is enabled, attempts to disable retention or
decrease the retention's duration MUST fail with the error
NFS4ERR_INVAL.
o If the principal attempting to change retention_set or
retentevt_set does not have ACE4_WRITE_RETENTION permissions, the
attempt MUST fail with NFS4ERR_ACCESS.
5.12.3. Attribute 71: retentevt_get 5.12.3. Attribute 71: retentevt_get
Get the event-based retention duration, and if enabled, the event- Get the event-based retention duration, and if enabled, the event-
based retention begin time of the file object. This attribute is based retention begin time of the file object. This attribute is
like retention_get but refers to event-based retention. The event like retention_get but refers to event-based retention. The event
that triggers event-based retention is not defined by the NFSv4.1 that triggers event-based retention is not defined by the NFSv4.1
specification. specification.
5.12.4. Attribute 72: retentevt_set 5.12.4. Attribute 72: retentevt_set
skipping to change at page 116, line 52 skipping to change at page 117, line 26
based retention on the file object. This attribute corresponds to based retention on the file object. This attribute corresponds to
retentevt_get, is like retention_set, but refers to event-based retentevt_get, is like retention_set, but refers to event-based
retention. When event based retention is set, the file MUST be retention. When event based retention is set, the file MUST be
retained even if non-event-based retention has been set, and the retained even if non-event-based retention has been set, and the
duration of non-event-based retention has been reached. Conversely, duration of non-event-based retention has been reached. Conversely,
when non-event-based retention has been set, the file MUST be when non-event-based retention has been set, the file MUST be
retained even if event-based retention has been set, and the duration retained even if event-based retention has been set, and the duration
of event-based retention has been reached. The server MAY restrict of event-based retention has been reached. The server MAY restrict
the enabling of event-based retention or the duration of event-based the enabling of event-based retention or the duration of event-based
retention on the basis of the ACE4_WRITE_RETENTION ACL permission. retention on the basis of the ACE4_WRITE_RETENTION ACL permission.
The enabling of event-based retention does not prevent the enabling The enabling of event-based retention MUST NOT prevent the enabling
of non-event-based retention nor the modification of the of non-event-based retention nor the modification of the
retention_hold attribute. retention_hold attribute.
5.12.5. Attribute 73: retention_hold 5.12.5. Attribute 73: retention_hold
Get or set administrative retention holds, one hold per bit position. Get or set administrative retention holds, one hold per bit position.
This attribute allows one to 64 administrative holds, one hold per This attribute allows one to 64 administrative holds, one hold per
bit on the attribute. If retention_hold is not zero, then the file bit on the attribute. If retention_hold is not zero, then the file
MUST NOT be deleted, renamed, or modified, even if the duration on MUST NOT be deleted, renamed, or modified, even if the duration on
enabled event or non-event-based retention has been reached. The enabled event or non-event-based retention has been reached. The
server MAY restrict the modification of retention_hold on the basis server MAY restrict the modification of retention_hold on the basis
of the ACE4_WRITE_RETENTION_HOLD ACL permission. The enabling of of the ACE4_WRITE_RETENTION_HOLD ACL permission. The enabling of
administration retention holds does not prevent the enabling of administration retention holds does not prevent the enabling of
event-based or non-event-based retention. event-based or non-event-based retention.
If the principal attempting to change retention_hold or not have
ACE4_WRITE_RETENTION_HOLD permissions, the attempt MUST fail with
NFS4ERR_ACCESS.
6. Access Control Attributes 6. Access Control Attributes
Access Control Lists (ACLs) are file attributes that specify fine Access Control Lists (ACLs) are file attributes that specify fine
grained access control. This chapter covers the "acl", "dacl", grained access control. This chapter covers the "acl", "dacl",
"sacl", "aclsupport", "mode", "mode_set_masked" file attributes, and "sacl", "aclsupport", "mode", "mode_set_masked" file attributes, and
their interactions. Note that file attributes may apply to any file their interactions. Note that file attributes may apply to any file
system object. system object.
6.1. Goals 6.1. Goals
skipping to change at page 391, line 47 skipping to change at page 391, line 47
object specified by the current filehandle. The client encodes the object specified by the current filehandle. The client encodes the
set of access rights that are to be checked in the bit mask "access". set of access rights that are to be checked in the bit mask "access".
The server checks the permissions encoded in the bit mask. If a The server checks the permissions encoded in the bit mask. If a
status of NFS4_OK is returned, two bit masks are included in the status of NFS4_OK is returned, two bit masks are included in the
response. The first, "supported", represents the access rights for response. The first, "supported", represents the access rights for
which the server can verify reliably. The second, "access", which the server can verify reliably. The second, "access",
represents the access rights available to the user for the filehandle represents the access rights available to the user for the filehandle
provided. On success, the current filehandle retains its value. provided. On success, the current filehandle retains its value.
Note that the reply's supported and access fields MUST NOT contain Note that the reply's supported and access fields MUST NOT contain
more values than originally sent in the requests access field. For more values than originally set in the request's access field. For
example, if the client sends an ACCESS operation with only the example, if the client sends an ACCESS operation with just the
ACCESS4_READ value set and the server supports this value, the server ACCESS4_READ value set and the server supports this value, the server
can set only ACCESS4_READ in the supported field even if it could MUST NOT set more than ACCESS4_READ in the supported field even if it
have reliably checked other values. could have reliably checked other values.
The reply's access field MUST NOT contain more values than in the The reply's access field MUST NOT contain more values than the
supported field. supported field.
The results of this operation are necessarily advisory in nature. A The results of this operation are necessarily advisory in nature. A
return status of NFS4_OK and the appropriate bit set in the bit mask return status of NFS4_OK and the appropriate bit set in the bit mask
does not imply that such access will be allowed to the file system does not imply that such access will be allowed to the file system
object in the future. This is because access rights can be revoked object in the future. This is because access rights can be revoked
by the server at any time. by the server at any time.
The following access permissions may be requested: The following access permissions may be requested:
skipping to change at page 392, line 48 skipping to change at page 392, line 48
o Whether a regular file is executable or not ought to be the o Whether a regular file is executable or not ought to be the
responsibility of the NFS client and not the server. And yet the responsibility of the NFS client and not the server. And yet the
ACCESS operation is specified to seemingly require a server to own ACCESS operation is specified to seemingly require a server to own
that responsibility. that responsibility.
o When a client executes a regular file, it has to read the file o When a client executes a regular file, it has to read the file
from the server. Strictly speaking, the server should not allow from the server. Strictly speaking, the server should not allow
the client to read a file being executed unless the user has read the client to read a file being executed unless the user has read
permissions on the file. Requiring users and administers to set permissions on the file. Requiring users and administers to set
read permissions on executable files in order to access them over read permissions on executable files in order to access them over
NFS is not going to be acceptable some people. Historically, NFS NFS is not going to be acceptable to some people. Historically,
servers have allowed a user to READ a file if the user has execute NFS servers have allowed a user to READ a file if the user has
access to the file. execute access to the file.
As a practical example, the UNIX specification [41] states that an As a practical example, the UNIX specification [41] states that an
implementation claiming conformance to UNIX may indicate in the implementation claiming conformance to UNIX may indicate in the
access() programming interface's result that a privileged user has access() programming interface's result that a privileged user has
execute rights, even if no execute permission bits are set on the execute rights, even if no execute permission bits are set on the
regular file's attributes. It is possible to claim conformance to regular file's attributes. It is possible to claim conformance to
the UNIX specification and instead not indicate execute rights in the UNIX specification and instead not indicate execute rights in
that situation, which is true for some operating enviroments. that situation, which is true for some operating enviroments.
Suppose the operating environments of the client and server are Suppose the operating environments of the client and server are
implementing the access() semantics for privileged users differently, implementing the access() semantics for privileged users differently,
and the ACCESS operation implementations of the client and server and the ACCESS operation implementations of the client and server
follow their respective access() semantics. This can cause undesired follow their respective access() semantics. This can cause undesired
behavior: behavior:
o Suppose the client's access() interface returns X_OK if the user o Suppose the client's access() interface returns X_OK if the user
is privileged, no execute permission bits are set on the regular is privileged and no execute permission bits are set on the
file's attribute, and the server's access() interface does not regular file's attribute, and the server's access() interface does
return X_OK in that situation. Then the client will be unable to not return X_OK in that situation. Then the client will be unable
execute files stored on the NFS server that could be executed if to execute files stored on the NFS server that could be executed
stored on a non-NFS file system. if stored on a non-NFS file system.
o Suppose the client's access() interface does not return X_OK if o Suppose the client's access() interface does not return X_OK if
the user is privileged, and no execute permission bits are set on the user is privileged, and no execute permission bits are set on
the regular file's attribute, and the server's access() interface the regular file's attribute, and the server's access() interface
does return X_OK in that situation. Then: does return X_OK in that situation. Then:
* The client will be able to execute files stored on the NFS * The client will be able to execute files stored on the NFS
server that could be executed if stored on a non-NFS file server that could be executed if stored on a non-NFS file
system, unless the client's execution subsystem also checks for system, unless the client's execution subsystem also checks for
execute permission bits. execute permission bits.
skipping to change at page 394, line 5 skipping to change at page 394, line 5
The path search table will indicate that the first directory The path search table will indicate that the first directory
has the executable file, but the execute subsystem will fail to has the executable file, but the execute subsystem will fail to
execute it. The command shell might fail to try the second execute it. The command shell might fail to try the second
file in the second directory. And even if it did, this is a file in the second directory. And even if it did, this is a
potential performance issue. Clearly the desired outcome for potential performance issue. Clearly the desired outcome for
the client is for the path search table to not contain the the client is for the path search table to not contain the
first file. first file.
To deal the problems described above, the smart client, stupid server To deal the problems described above, the smart client, stupid server
principle is used. The client owns overall responsibility for principle is used. The client owns overall responsibility for
determining execute access, and relies on the server to parse the determining execute access and relies on the server to parse the
execution permissions within the file's mode, acl, and dacl execution permissions within the file's mode, acl, and dacl
attributes. The rules for the client and server follow: attributes. The rules for the client and server follow:
o If the client is sending ACCESS in order to determine if the user o If the client is sending ACCESS in order to determine if the user
can read the file, the client SHOULD set ACCESS4_READ in the can read the file, the client SHOULD set ACCESS4_READ in the
request's access field. request's access field.
o If the client's operating environment only grants execution to the o If the client's operating environment only grants execution to the
user if the user has execute access according to the execute user if the user has execute access according to the execute
permissions in the mode, acl, and dacl attributes, then if the permissions in the mode, acl, and dacl attributes, then if the
client wants to determine execute access, the client SHOULD send client wants to determine execute access, the client SHOULD send
an ACCESS request with ACCESS4_EXECUTE bit set in the request's an ACCESS request with ACCESS4_EXECUTE bit set in the request's
access field. access field.
o If the client's operating environment grants execution to the user o If the client's operating environment grants execution to the user
even if the user does not have execute access according to the even if the user does not have execute access according to the
execute permissions in the mode, acl, and dacl attributes, then if execute permissions in the mode, acl, and dacl attributes, then if
the client wants to determine execute access, it SHOULD send an the client wants to determine execute access, it SHOULD send an
ACCESS request with both the ACCESS4_EXECUTE and ACCESS4_READ bits ACCESS request with both the ACCESS4_EXECUTE and ACCESS4_READ bits
set the request's access field. This way, if any read or execute set in the request's access field. This way, if any read or
permission grants the user read or execute access (or if the execute permission grants the user read or execute access (or if
server interprets the user as privileged), as indicated by the the server interprets the user as privileged), as indicated by the
presence of ACCESS4_EXECUTE and/or ACCESS4_READ in the reply's presence of ACCESS4_EXECUTE and/or ACCESS4_READ in the reply's
access field, the client will be able to grant the user execute access field, the client will be able to grant the user execute
access to the file. access to the file.
o If the server supports execute permission bits, it MUST check just o If the server supports execute permission bits, or some other
the execute permissions in the mode, acl, and dacl attributes when method for denoting executability (e.g. the suffix of the name of
it receives an ACCESS request with ACCESS4_EXECUTE set the access the file might indicate execute), it MUST check only execute
field. The server MUST NOT also examine read permission bits when permissions, not read permissions, when determining whether the
reply will have ACCESS4_EXECUTE set in the access field or not.
The server MUST NOT also examine read permission bits when
determining whether the reply will have ACCESS4_EXECUTE set in the determining whether the reply will have ACCESS4_EXECUTE set in the
access field or not. Even if the server's operating environment access field or not. Even if the server's operating environment
would grant execute access to the user (e.g., the user is would grant execute access to the user (e.g., the user is
privileged), the server MUST NOT reply with ACCESS4_EXECUTE set in privileged), the server MUST NOT reply with ACCESS4_EXECUTE set in
reply's access field, unless there is at least one execute reply's access field, unless there is at least one execute
permission bit set in the mode, acl, or dacl attributes. In the permission bit set in the mode, acl, or dacl attributes. In the
case of acl and dacl, the "one execute permission bit" MUST be an case of acl and dacl, the "one execute permission bit" MUST be an
ACE4_EXECUTE bit set in an ALLOW ACE. ACE4_EXECUTE bit set in an ALLOW ACE.
o If the server does not support execute permission bits, it MUST o If the server does not support execute permission bits or some
NOT set ACCESS4_EXECUTE in the reply's supported and access other method for denoting executability, it MUST NOT set
fields. If the client set ACCESS4_EXECUTE in the ACCESS request's ACCESS4_EXECUTE in the reply's supported and access fields. If
access field, and ACCESS4_EXECUTE is not set in the reply's the client set ACCESS4_EXECUTE in the ACCESS request's access
supported field, then the client will have to send an ACCESS field, and ACCESS4_EXECUTE is not set in the reply's supported
request with the ACCESS4_READ bit set in the request's access field, then the client will have to send an ACCESS request with
field. the ACCESS4_READ bit set in the request's access field.
o If the server supports read permission bits, it MUST only check o If the server supports read permission bits, it MUST only check
for read permissions in the mode, acl, and dacl attributes when it for read permissions in the mode, acl, and dacl attributes when it
receives an ACCESS request with ACCESS4_READ set the access field. receives an ACCESS request with ACCESS4_READ set the access field.
The server MUST NOT also examine execute permission bits when The server MUST NOT also examine execute permission bits when
determining whether the reply will have ACCESS4_READ set in the determining whether the reply will have ACCESS4_READ set in the
access field or not. access field or not.
Note that if the ACCESS reply has ACCESS4_READ or ACCESS_EXECUTE set, Note that if the ACCESS reply has ACCESS4_READ or ACCESS_EXECUTE set,
then the user also has permissions to OPEN (Section 18.16) or READ then the user also has permissions to OPEN (Section 18.16) or READ
 End of changes. 36 change blocks. 
64 lines changed or deleted 96 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/