Found wdiff, but it reported no recognisable version. Falling back to builtin diff colouring...
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/ |