draft-ietf-nfsv4-rfc3530bis-12.txt   draft-ietf-nfsv4-rfc3530bis-13.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track D. Noveck, Ed. Intended status: Standards Track D. Noveck, Ed.
Expires: October 10, 2011 EMC Expires: February 17, 2012 EMC
April 08, 2011 August 16, 2011
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-12.txt draft-ietf-nfsv4-rfc3530bis-13.txt
Abstract Abstract
The Network File System (NFS) version 4 is a distributed filesystem The Network File System (NFS) version 4 is a distributed filesystem
protocol which owes heritage to NFS protocol version 2, RFC 1094, and protocol which owes heritage to NFS protocol version 2, RFC 1094, and
version 3, RFC 1813. Unlike earlier versions, the NFS version 4 version 3, RFC 1813. Unlike earlier versions, the NFS version 4
protocol supports traditional file access while integrating support protocol supports traditional file access while integrating support
for file locking and the mount protocol. In addition, support for for file locking and the mount protocol. In addition, support for
strong security (and its negotiation), compound operations, client strong security (and its negotiation), compound operations, client
caching, and internationalization have been added. Of course, caching, and internationalization have been added. Of course,
attention has been applied to making NFS version 4 operate well in an attention has been applied to making NFS version 4 operate well in an
Internet environment. Internet environment.
This document, together with the companion XDR description document, This document, together with the companion XDR description document,
replaces RFC 3530 as the definition of the NFS version 4 protocol. RFCNFSv4XDR, replaces RFC 3530 as the definition of the NFS version 4
protocol.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2011. This Internet-Draft will expire on February 17, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
1.5.6. Client Caching and Delegation . . . . . . . . . . . 15 1.5.6. Client Caching and Delegation . . . . . . . . . . . 15
1.6. General Definitions . . . . . . . . . . . . . . . . . . 16 1.6. General Definitions . . . . . . . . . . . . . . . . . . 16
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 18 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 18
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 18 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 18
2.2. Structured Data Types . . . . . . . . . . . . . . . . . 20 2.2. Structured Data Types . . . . . . . . . . . . . . . . . 20
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 25 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 25
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 25 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 25
3.1.1. Client Retransmission Behavior . . . . . . . . . . . 26 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 26
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 27 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 27
3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 27 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 27
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 29 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 28
3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 30 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 30 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28
3.3.3. Callback RPC Authentication . . . . . . . . . . . . 30 3.3.3. Callback RPC Authentication . . . . . . . . . . . . 29
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 32 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 32 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 30
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 33 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 30
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 33 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 31
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 33 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 31
4.2.1. General Properties of a Filehandle . . . . . . . . . 34 4.2.1. General Properties of a Filehandle . . . . . . . . . 31
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 34 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 32
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 35 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 32
4.2.4. One Method of Constructing a Volatile Filehandle . . 36 4.2.4. One Method of Constructing a Volatile Filehandle . . 34
4.3. Client Recovery from Filehandle Expiration . . . . . . . 36 4.3. Client Recovery from Filehandle Expiration . . . . . . . 34
5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 37 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 38 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 36
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 39 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 36
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 39 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 37
5.4. Classification of Attributes . . . . . . . . . . . . . . 41 5.4. Classification of Attributes . . . . . . . . . . . . . . 38
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 41 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39
5.6. REQUIRED Attributes - List and Definition References . . 42 5.6. REQUIRED Attributes - List and Definition References . . 39
5.7. RECOMMENDED Attributes - List and Definition 5.7. RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 43 References . . . . . . . . . . . . . . . . . . . . . . . 40
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 44 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 44 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41
5.8.2. Definitions of Uncategorized RECOMMENDED 5.8.2. Definitions of Uncategorized RECOMMENDED
Attributes . . . . . . . . . . . . . . . . . . . . . 46 Attributes . . . . . . . . . . . . . . . . . . . . . 44
5.9. Interpreting owner and owner_group . . . . . . . . . . . 52 5.9. Interpreting owner and owner_group . . . . . . . . . . . 50
5.10. Character Case Attributes . . . . . . . . . . . . . . . 55 5.10. Character Case Attributes . . . . . . . . . . . . . . . 53
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 55 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 53
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 55 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 56 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 54
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 56 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 54
6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 70 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 71 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 69
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 71 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 69
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 72 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 70
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 73 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 71
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 73 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 75 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 73
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 75 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 73
7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 77 7. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 75
7.1. Location Attributes . . . . . . . . . . . . . . . . . . 77 7.1. Location Attributes . . . . . . . . . . . . . . . . . . 75
7.2. File System Presence or Absence . . . . . . . . . . . . 77 7.2. File System Presence or Absence . . . . . . . . . . . . 75
7.3. Getting Attributes for an Absent File System . . . . . . 78 7.3. Getting Attributes for an Absent File System . . . . . . 76
7.3.1. GETATTR Within an Absent File System . . . . . . . . 79 7.3.1. GETATTR Within an Absent File System . . . . . . . . 77
7.3.2. READDIR and Absent File Systems . . . . . . . . . . 80 7.3.2. READDIR and Absent File Systems . . . . . . . . . . 78
7.4. Uses of Location Information . . . . . . . . . . . . . . 80 7.4. Uses of Location Information . . . . . . . . . . . . . . 78
7.4.1. File System Replication . . . . . . . . . . . . . . 81 7.4.1. File System Replication . . . . . . . . . . . . . . 79
7.4.2. File System Migration . . . . . . . . . . . . . . . 82 7.4.2. File System Migration . . . . . . . . . . . . . . . 80
7.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 82 7.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 80
7.5. Location Entries and Server Identity . . . . . . . . . . 83 7.5. Location Entries and Server Identity . . . . . . . . . . 81
7.6. Additional Client-Side Considerations . . . . . . . . . 84 7.6. Additional Client-Side Considerations . . . . . . . . . 82
7.7. Effecting File System Transitions . . . . . . . . . . . 85 7.7. Effecting File System Transitions . . . . . . . . . . . 83
7.7.1. File System Transitions and Simultaneous Access . . 86 7.7.1. File System Transitions and Simultaneous Access . . 84
7.7.2. Filehandles and File System Transitions . . . . . . 86 7.7.2. Filehandles and File System Transitions . . . . . . 84
7.7.3. Fileids and File System Transitions . . . . . . . . 87 7.7.3. Fileids and File System Transitions . . . . . . . . 85
7.7.4. Fsids and File System Transitions . . . . . . . . . 88 7.7.4. Fsids and File System Transitions . . . . . . . . . 86
7.7.5. The Change Attribute and File System Transitions . . 88 7.7.5. The Change Attribute and File System Transitions . . 86
7.7.6. Lock State and File System Transitions . . . . . . . 89 7.7.6. Lock State and File System Transitions . . . . . . . 87
7.7.7. Write Verifiers and File System Transitions . . . . 91 7.7.7. Write Verifiers and File System Transitions . . . . 89
7.7.8. Readdir Cookies and Verifiers and File System 7.7.8. Readdir Cookies and Verifiers and File System
Transitions . . . . . . . . . . . . . . . . . . . . 91 Transitions . . . . . . . . . . . . . . . . . . . . 89
7.7.9. File System Data and File System Transitions . . . . 91 7.7.9. File System Data and File System Transitions . . . . 89
7.8. Effecting File System Referrals . . . . . . . . . . . . 93 7.8. Effecting File System Referrals . . . . . . . . . . . . 91
7.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 93 7.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 91
7.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 97 7.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 95
7.9. The Attribute fs_locations . . . . . . . . . . . . . . . 99 7.9. The Attribute fs_locations . . . . . . . . . . . . . . . 97
7.9.1. Inferring Transition Modes . . . . . . . . . . . . . 101 7.9.1. Inferring Transition Modes . . . . . . . . . . . . . 99
8. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 102 8. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 100
8.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 103 8.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 101
8.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 103 8.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 101
8.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 103 8.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 101
8.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 104 8.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 102
8.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 104 8.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 102
8.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 104 8.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 102
8.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 105 8.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 103
8.8. Security Policy and Name Space Presentation . . . . . . 105 8.8. Security Policy and Name Space Presentation . . . . . . 103
9. File Locking and Share Reservations . . . . . . . . . . . . . 106 9. File Locking and Share Reservations . . . . . . . . . . . . . 104
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 107 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 105
9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 107 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 105
9.1.2. Server Release of Client ID . . . . . . . . . . . . 110 9.1.2. Server Release of Client ID . . . . . . . . . . . . 108
9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 111 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 109
9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 118 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 116
9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 119 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 117
9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 121 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 119
9.1.7. Recovery from Replayed Requests . . . . . . . . . . 122 9.1.7. Recovery from Replayed Requests . . . . . . . . . . 120
9.1.8. Releasing state-owner State . . . . . . . . . . . . 122 9.1.8. Interactions of multiple sequence values . . . . . . 120
9.1.9. Use of Open Confirmation . . . . . . . . . . . . . . 123 9.1.9. Releasing state-owner State . . . . . . . . . . . . 121
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 124 9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 122
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 123
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 124 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 124
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 125 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 124
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 125 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 125
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 126 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 126
9.6.1. Client Failure and Recovery . . . . . . . . . . . . 127 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 126
9.6.2. Server Failure and Recovery . . . . . . . . . . . . 127 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 127
9.6.3. Network Partitions and Recovery . . . . . . . . . . 129 9.6.3. Network Partitions and Recovery . . . . . . . . . . 129
9.7. Recovery from a Lock Request Timeout or Abort . . . . . 135 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 135
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 136 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 135
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 137 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 137
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 138 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 137
9.10.1. Close and Retention of State Information . . . . . . 138 9.10.1. Close and Retention of State Information . . . . . . 138
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 139 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 139
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 140 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 140
9.13. Clocks, Propagation Delay, and Calculating Lease 9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 140 Expiration . . . . . . . . . . . . . . . . . . . . . . . 140
9.14. Migration, Replication and State . . . . . . . . . . . . 141 9.14. Migration, Replication and State . . . . . . . . . . . . 141
9.14.1. Migration and State . . . . . . . . . . . . . . . . 141 9.14.1. Migration and State . . . . . . . . . . . . . . . . 141
9.14.2. Replication and State . . . . . . . . . . . . . . . 142 9.14.2. Replication and State . . . . . . . . . . . . . . . 142
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 143 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 142
9.14.4. Migration and the Lease_time Attribute . . . . . . . 143 9.14.4. Migration and the Lease_time Attribute . . . . . . . 143
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 144 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 144
10.1. Performance Challenges for Client-Side Caching . . . . . 145 10.1. Performance Challenges for Client-Side Caching . . . . . 144
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 146 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 145
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 147 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 147
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 149 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 149
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 150 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 149
10.3.2. Data Caching and File Locking . . . . . . . . . . . 151 10.3.2. Data Caching and File Locking . . . . . . . . . . . 150
10.3.3. Data Caching and Mandatory File Locking . . . . . . 152 10.3.3. Data Caching and Mandatory File Locking . . . . . . 152
10.3.4. Data Caching and File Identity . . . . . . . . . . . 153 10.3.4. Data Caching and File Identity . . . . . . . . . . . 152
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 153
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 154
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 156 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 156
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 157 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 157
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 158 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 157
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 161 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 160
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 163 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 162
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 163 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 163
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 164 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 164
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 165 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 164
10.5.1. Revocation Recovery for Write Open Delegation . . . 165 10.5.1. Revocation Recovery for Write Open Delegation . . . 165
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 166 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 165
10.7. Data and Metadata Caching and Memory Mapped Files . . . 168 10.7. Data and Metadata Caching and Memory Mapped Files . . . 167
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 170 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 170
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 171 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 171
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 172 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 171
12. Internationalization . . . . . . . . . . . . . . . . . . . . 175 12. Internationalization . . . . . . . . . . . . . . . . . . . . 174
12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 176 12.1. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . . . 175
12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 176 12.1.1. Relation to Stringprep . . . . . . . . . . . . . . . 175
12.1.2. Normalization, Equivalence, and Confusability . . . 177 12.1.2. Normalization, Equivalence, and Confusability . . . 176
12.2. String Type Overview . . . . . . . . . . . . . . . . . . 179 12.2. String Type Overview . . . . . . . . . . . . . . . . . . 179
12.2.1. Overall String Class Divisions . . . . . . . . . . . 180 12.2.1. Overall String Class Divisions . . . . . . . . . . . 179
12.2.2. Divisions by Typedef Parent types . . . . . . . . . 181 12.2.2. Divisions by Typedef Parent types . . . . . . . . . 180
12.2.3. Individual Types and Their Handling . . . . . . . . 181 12.2.3. Individual Types and Their Handling . . . . . . . . 181
12.3. Errors Related to Strings . . . . . . . . . . . . . . . 183 12.3. Errors Related to Strings . . . . . . . . . . . . . . . 182
12.4. Types with Pre-processing to Resolve Mixture Issues . . 184 12.4. Types with Pre-processing to Resolve Mixture Issues . . 183
12.4.1. Processing of Principal Strings . . . . . . . . . . 184 12.4.1. Processing of Principal Strings . . . . . . . . . . 183
12.4.2. Processing of Server Id Strings . . . . . . . . . . 184 12.4.2. Processing of Server Id Strings . . . . . . . . . . 183
12.5. String Types without Internationalization Processing . . 185 12.5. String Types without Internationalization Processing . . 184
12.6. Types with Processing Defined by Other Internet Areas . 185 12.6. Types with Processing Defined by Other Internet Areas . 184
12.7. String Types with NFS-specific Processing . . . . . . . 186 12.7. String Types with NFS-specific Processing . . . . . . . 185
12.7.1. Handling of File Name Components . . . . . . . . . . 187 12.7.1. Handling of File Name Components . . . . . . . . . . 186
12.7.2. Processing of Link Text . . . . . . . . . . . . . . 196 12.7.2. Processing of Link Text . . . . . . . . . . . . . . 195
12.7.3. Processing of Principal Prefixes . . . . . . . . . . 197 12.7.3. Processing of Principal Prefixes . . . . . . . . . . 196
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 198 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 197
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 198 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 197
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 199 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 199
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 201 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 200
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 202 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 201
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 203 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 202
13.1.5. State Management Errors . . . . . . . . . . . . . . 205 13.1.5. State Management Errors . . . . . . . . . . . . . . 204
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 206 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 205
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 206 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 205
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 207 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 206
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 208 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 207
13.1.10. Client Management Errors . . . . . . . . . . . . . . 209 13.1.10. Client Management Errors . . . . . . . . . . . . . . 208
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 209 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 208
13.2. Operations and their valid errors . . . . . . . . . . . 210 13.2. Operations and their valid errors . . . . . . . . . . . 209
13.3. Callback operations and their valid errors . . . . . . . 217 13.3. Callback operations and their valid errors . . . . . . . 216
13.4. Errors and the operations that use them . . . . . . . . 217 13.4. Errors and the operations that use them . . . . . . . . 216
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 222 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 221
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 222 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 221
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 223 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 222
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 224 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 223
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 224 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 223
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 224 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 223
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 224 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 223
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 225 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 224
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 230 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 229
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 233 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 232
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 234 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 233
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 236 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 235
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 239 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 238
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 240 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 239
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 240 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 239
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 242 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 241
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 243 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 242
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 244 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 243
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 248 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 247
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 250 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 249
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 251 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 250
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 253 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 252
15.17. Operation 17: NVERIFY - Verify Difference in 15.17. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . . 253 Attributes . . . . . . . . . . . . . . . . . . . . . . . 253
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 255 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 254
15.19. Operation 19: OPENATTR - Open Named Attribute 15.19. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . . 265 Directory . . . . . . . . . . . . . . . . . . . . . . . 264
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 266 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 265
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 268 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 267
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 269 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 268
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 270 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 269
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 271 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 270
15.25. Operation 25: READ - Read from File . . . . . . . . . . 272 15.25. Operation 25: READ - Read from File . . . . . . . . . . 271
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 274 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 273
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 278 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 277
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 279 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 278
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 281 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 280
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 283 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 282
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 284 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 283
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 285 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 284
15.33. Operation 33: SECINFO - Obtain Available Security . . . 285 15.33. Operation 33: SECINFO - Obtain Available Security . . . 285
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 288 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 288
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 291 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 291
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 295 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 294
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 298 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 298
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 300 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 299
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 304 State . . . . . . . . . . . . . . . . . . . . . . . . . 303
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 305 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 304
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 305 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 305
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 306 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 305
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 306 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 306
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 308 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 308
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 309 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 309
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 310 Operation . . . . . . . . . . . . . . . . . . . . . 310
17. Security Considerations . . . . . . . . . . . . . . . . . . . 311 17. Security Considerations . . . . . . . . . . . . . . . . . . . 310
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 312 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 312
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 312 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 312
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 313 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 313
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 313 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 313
18.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 313 18.2. ONC RPC Network Identifiers (netids) . . . . . . . . . . 313
18.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 315 18.2.1. Initial Registry . . . . . . . . . . . . . . . . . . 314
18.2.2. Updating Registrations . . . . . . . . . . . . . . . 315 18.2.2. Updating Registrations . . . . . . . . . . . . . . . 314
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 315 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 315
19.1. Normative References . . . . . . . . . . . . . . . . . . 315 19.1. Normative References . . . . . . . . . . . . . . . . . . 315
19.2. Informative References . . . . . . . . . . . . . . . . . 316 19.2. Informative References . . . . . . . . . . . . . . . . . 315
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 318 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 318
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 319 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 318
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 319 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 319
1. Introduction 1. Introduction
1.1. Changes since RFC 3530 1.1. Changes since RFC 3530
This document, together with the companion XDR description document This document, together with the companion XDR description document
[2], obsoletes RFC 3530 [11] as the authoritative document describing [2], obsoletes RFC 3530 [10] as the authoritative document describing
NFSv4. It does not introduce any over-the-wire protocol changes, in NFSv4. It does not introduce any over-the-wire protocol changes, in
the sense that previously valid requests requests remain valid. the sense that previously valid requests requests remain valid.
However, some requests previously defined as invalid, although not However, some requests previously defined as invalid, although not
generally rejected, are now explicitly allowed, in that generally rejected, are now explicitly allowed, in that
internationalization handling has been generalized and liberalized. internationalization handling has been generalized and liberalized.
The main changes from RFC 3530 are: The main changes from RFC 3530 are:
o The XDR definition has been moved to a companion document [2] o The XDR definition has been moved to a companion document [2]
o Updates for the latest IETF intellectual property statements o Updates for the latest IETF intellectual property statements
skipping to change at page 9, line 32 skipping to change at page 9, line 32
o There is a restructured and more complete explanation of multi- o There is a restructured and more complete explanation of multi-
server namespace features. In particular, this explanation server namespace features. In particular, this explanation
explicitly describes handling of inter-server referrals, even explicitly describes handling of inter-server referrals, even
where neither migration nor replication is involved. where neither migration nor replication is involved.
o More liberal handling of internationalization for file names and o More liberal handling of internationalization for file names and
user and group names, with the elimination of restrictions imposed user and group names, with the elimination of restrictions imposed
by stringprep, with the recognition that rules for the forms of by stringprep, with the recognition that rules for the forms of
these name are the province of the receiving entity. these name are the province of the receiving entity.
o Updating handling of domain names to reflect IDNA. o Updating handling of domain names to reflect IDNA [3].
o Restructuring of string types to more appropriately reflect the o Restructuring of string types to more appropriately reflect the
reality of required string processing. reality of required string processing.
o LIPKEY SPKM/3 has been moved from being REQUIRED to OPTIONAL. o LIPKEY SPKM/3 has been moved from being REQUIRED to being removed.
o Some clarification on a client re-establishing callback o Some clarification on a client re-establishing callback
information to the new server if state has been migrated. information to the new server if state has been migrated.
o A third edge case was added for Courtesy locks and network o A third edge case was added for Courtesy locks and network
partitions. partitions.
o The definition of stateid was strengthened, which had the side o The definition of stateid was strengthened, which had the side
effect of introducing a semantic change in a COMPOUND structure effect of introducing a semantic change in a COMPOUND structure
having a current stateid and a saved stateid. having a current stateid and a saved stateid.
1.2. Changes since RFC 3010 1.2. Changes since RFC 3010
This definition of the NFSv4 protocol replaces or obsoletes the This definition of the NFSv4 protocol replaces or obsoletes the
definition present in [12]. While portions of the two documents have definition present in [11]. While portions of the two documents have
remained the same, there have been substantive changes in others. remained the same, there have been substantive changes in others.
The changes made between [12] and this document represent The changes made between [11] and this document represent
implementation experience and further review of the protocol. While implementation experience and further review of the protocol. While
some modifications were made for ease of implementation or some modifications were made for ease of implementation or
clarification, most updates represent errors or situations where the clarification, most updates represent errors or situations where the
[12] definition were untenable. [11] definition were untenable.
The following list is not all inclusive of all changes but presents The following list is not all inclusive of all changes but presents
some of the most notable changes or additions made: some of the most notable changes or additions made:
o The state model has added an open_owner4 identifier. This was o The state model has added an open_owner4 identifier. This was
done to accommodate Posix based clients and the model they use for done to accommodate Posix based clients and the model they use for
file locking. For Posix clients, an open_owner4 would correspond file locking. For Posix clients, an open_owner4 would correspond
to a file descriptor potentially shared amongst a set of processes to a file descriptor potentially shared amongst a set of processes
and the lock_owner4 identifier would correspond to a process that and the lock_owner4 identifier would correspond to a process that
is locking a file. is locking a file.
skipping to change at page 11, line 17 skipping to change at page 11, line 17
o Remove use of the pathname4 data type from LOOKUP and OPEN in o Remove use of the pathname4 data type from LOOKUP and OPEN in
favor of having the client construct a sequence of LOOKUP favor of having the client construct a sequence of LOOKUP
operations to achieve the same effect. operations to achieve the same effect.
o Clarification of the internationalization issues and adoption of o Clarification of the internationalization issues and adoption of
the new stringprep profile framework. the new stringprep profile framework.
1.3. NFS Version 4 Goals 1.3. NFS Version 4 Goals
The NFSv4 protocol is a further revision of the NFS protocol defined The NFSv4 protocol is a further revision of the NFS protocol defined
already by versions 2 [13] and 3 [14]. It retains the essential already by versions 2 [12] and 3 [13]. It retains the essential
characteristics of previous versions: design for easy recovery, characteristics of previous versions: design for easy recovery,
independent of transport protocols, operating systems and independent of transport protocols, operating systems and
filesystems, simplicity, and good performance. The NFSv4 revision filesystems, simplicity, and good performance. The NFSv4 revision
has the following goals: has the following goals:
o Improved access and good performance on the Internet. o Improved access and good performance on the Internet.
The protocol is designed to transit firewalls easily, perform well The protocol is designed to transit firewalls easily, perform well
where latency is high and bandwidth is low, and scale to very where latency is high and bandwidth is low, and scale to very
large numbers of clients per server. large numbers of clients per server.
skipping to change at page 12, line 18 skipping to change at page 12, line 18
authoritative. authoritative.
1.5. Overview of NFSv4 Features 1.5. Overview of NFSv4 Features
To provide a reasonable context for the reader, the major features of To provide a reasonable context for the reader, the major features of
NFSv4 protocol will be reviewed in brief. This will be done to NFSv4 protocol will be reviewed in brief. This will be done to
provide an appropriate context for both the reader who is familiar provide an appropriate context for both the reader who is familiar
with the previous versions of the NFS protocol and the reader that is with the previous versions of the NFS protocol and the reader that is
new to the NFS protocols. For the reader new to the NFS protocols, new to the NFS protocols. For the reader new to the NFS protocols,
there is still a fundamental knowledge that is expected. The reader there is still a fundamental knowledge that is expected. The reader
should be familiar with the XDR and RPC protocols as described in [3] should be familiar with the XDR and RPC protocols as described in [4]
and [15]. A basic knowledge of filesystems and distributed and [14]. A basic knowledge of filesystems and distributed
filesystems is expected as well. filesystems is expected as well.
1.5.1. RPC and Security 1.5.1. RPC and Security
As with previous versions of NFS, the External Data Representation As with previous versions of NFS, the External Data Representation
(XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4 (XDR) and Remote Procedure Call (RPC) mechanisms used for the NFSv4
protocol are those defined in [3] and [15]. To meet end to end protocol are those defined in [4] and [14]. To meet end to end
security requirements, the RPCSEC_GSS framework [4] will be used to security requirements, the RPCSEC_GSS framework [5] will be used to
extend the basic RPC security. With the use of RPCSEC_GSS, various extend the basic RPC security. With the use of RPCSEC_GSS, various
mechanisms can be provided to offer authentication, integrity, and mechanisms can be provided to offer authentication, integrity, and
privacy to the NFS version 4 protocol. Kerberos V5 will be used as privacy to the NFS version 4 protocol. Kerberos V5 will be used as
described in [16] to provide one security framework. The LIPKEY GSS- described in [15] to provide one security framework. With the use of
API mechanism described in [5] will be used to provide for the use of RPCSEC_GSS, other mechanisms may also be specified and used for NFS
user password and server public key by the NFSv4 protocol. With the version 4 security.
use of RPCSEC_GSS, other mechanisms may also be specified and used
for NFS version 4 security.
To enable in-band security negotiation, the NFSv4 protocol has added To enable in-band security negotiation, the NFSv4 protocol has added
a new operation which provides the client a method of querying the a new operation which provides the client a method of querying the
server about its policies regarding which security mechanisms must be server about its policies regarding which security mechanisms must be
used for access to the server's filesystem resources. With this, the used for access to the server's filesystem resources. With this, the
client can securely match the security mechanism that meets the client can securely match the security mechanism that meets the
policies specified at both the client and server. policies specified at both the client and server.
1.5.2. Procedure and Operation Structure 1.5.2. Procedure and Operation Structure
skipping to change at page 14, line 18 skipping to change at page 14, line 16
filehandle being provided by the server and can be prepared to deal filehandle being provided by the server and can be prepared to deal
with the semantics of each. with the semantics of each.
1.5.3.2. Attribute Types 1.5.3.2. Attribute Types
The NFSv4 protocol has a rich and extensible file object attribute The NFSv4 protocol has a rich and extensible file object attribute
structure, which is divided into REQUIRED, RECOMMENDED, and named structure, which is divided into REQUIRED, RECOMMENDED, and named
attributes (see Section 5). attributes (see Section 5).
Several (but not all) of the REQUIRED attributes are derived from the Several (but not all) of the REQUIRED attributes are derived from the
attributes of NFSv3 (see definition of the fattr3 data type in [14]). attributes of NFSv3 (see definition of the fattr3 data type in [13]).
An example of a REQUIRED attribute is the file object's type An example of a REQUIRED attribute is the file object's type
(Section 5.8.1.2) so that regular files can be distinguished from (Section 5.8.1.2) so that regular files can be distinguished from
directories (also known as folders in some operating environments) directories (also known as folders in some operating environments)
and other types of objects. REQUIRED attributes are discussed in and other types of objects. REQUIRED attributes are discussed in
Section 5.1. Section 5.1.
An example of three RECOMMENDED attributes are acl, sacl, and dacl. An example of the RECOMMENDED attributes is an acl. This attribute
These attributes define an Access Control List (ACL) on a file object defines an Access Control List (ACL) on a file object ((Section 6).
((Section 6). An ACL provides directory and file access control An ACL provides file access control beyond the model used in NFSv3.
beyond the model used in NFSv3. The ACL definition allows for The ACL definition allows for specification of specific sets of
specification of specific sets of permissions for individual users permissions for individual users and groups. In addition, ACL
and groups. In addition, ACL inheritance allows propagation of inheritance allows propagation of access permissions and restriction
access permissions and restriction down a directory tree as file down a directory tree as file system objects are created.
system objects are created. RECOMMENDED attributes are discussed in RECOMMENDED attributes are discussed in Section 5.2.
Section 5.2.
A named attribute is an opaque byte stream that is associated with a A named attribute is an opaque byte stream that is associated with a
directory or file and referred to by a string name. Named attributes directory or file and referred to by a string name. Named attributes
are meant to be used by client applications as a method to associate are meant to be used by client applications as a method to associate
application-specific data with a regular file or directory. NFSv4.1 application-specific data with a regular file or directory. NFSv4.1
modifies named attributes relative to NFSv4.0 by tightening the modifies named attributes relative to NFSv4.0 by tightening the
allowed operations in order to prevent the development of non- allowed operations in order to prevent the development of non-
interoperable implementations. Named attributes are discussed in interoperable implementations. Named attributes are discussed in
Section 5.3. Section 5.3.
skipping to change at page 18, line 26 skipping to change at page 18, line 23
server for a specific open-owner or lock-owner/open-owner pair for server for a specific open-owner or lock-owner/open-owner pair for
a specific file and type of lock. a specific file and type of lock.
Verifier: A 64-bit quantity generated by the client that the server Verifier: A 64-bit quantity generated by the client that the server
can use to determine if the client has restarted and lost all can use to determine if the client has restarted and lost all
previous lock state. previous lock state.
2. Protocol Data Types 2. Protocol Data Types
The syntax and semantics to describe the data types of the NFS The syntax and semantics to describe the data types of the NFS
version 4 protocol are defined in the XDR [15] and RPC [3] documents. version 4 protocol are defined in the XDR [14] and RPC [4] documents.
The next sections build upon the XDR data types to define types and The next sections build upon the XDR data types to define types and
structures specific to this protocol. structures specific to this protocol.
2.1. Basic Data Types 2.1. Basic Data Types
These are the base NFSv4 data types. These are the base NFSv4 data types.
+----------------+--------------------------------------------------+ +----------------------+--------------------------------------------+
| Data Type | Definition | | Data Type | Definition |
+----------------+--------------------------------------------------+ +----------------------+--------------------------------------------+
| int32_t | typedef int int32_t; | | int32_t | typedef int int32_t; |
| uint32_t | typedef unsigned int uint32_t; | | uint32_t | typedef unsigned int uint32_t; |
| int64_t | typedef hyper int64_t; | | int64_t | typedef hyper int64_t; |
| uint64_t | typedef unsigned hyper uint64_t; | | uint64_t | typedef unsigned hyper uint64_t; |
| attrlist4 | typedef opaque attrlist4<>; | | attrlist4 | typedef opaque attrlist4<>; |
| | Used for file/directory attributes. | | | Used for file/directory attributes. |
| bitmap4 | typedef uint32_t bitmap4<>; | | bitmap4 | typedef uint32_t bitmap4<>; |
| | Used in attribute array encoding. | | | Used in attribute array encoding. |
| changeid4 | typedef uint64_t changeid4; | | changeid4 | typedef uint64_t changeid4; |
| | Used in the definition of change_info4. | | | Used in the definition of change_info4. |
| clientid4 | typedef uint64_t clientid4; | | clientid4 | typedef uint64_t clientid4; |
| | Shorthand reference to client identification. | | | Shorthand reference to client |
| count4 | typedef uint32_t count4; | | | identification. |
| | Various count parameters (READ, WRITE, COMMIT). | | count4 | typedef uint32_t count4; |
| length4 | typedef uint64_t length4; | | | Various count parameters (READ, WRITE, |
| | Describes LOCK lengths. | | | COMMIT). |
| mode4 | typedef uint32_t mode4; | | length4 | typedef uint64_t length4; |
| | Mode attribute data type. | | | Describes LOCK lengths. |
| nfs_cookie4 | typedef uint64_t nfs_cookie4; | | mode4 | typedef uint32_t mode4; |
| | Opaque cookie value for READDIR. | | | Mode attribute data type. |
| nfs_fh4 | typedef opaque nfs_fh4<NFS4_FHSIZE>; | | nfs_cookie4 | typedef uint64_t nfs_cookie4; |
| | Filehandle definition. | | | Opaque cookie value for READDIR. |
| nfs_ftype4 | enum nfs_ftype4; | | nfs_fh4 | typedef opaque nfs_fh4<NFS4_FHSIZE>; |
| | Various defined file types. | | | Filehandle definition. |
| nfsstat4 | enum nfsstat4; | | nfs_ftype4 | enum nfs_ftype4; |
| | Return value for operations. | | | Various defined file types. |
| offset4 | typedef uint64_t offset4; | | nfsstat4 | enum nfsstat4; |
| | Various offset designations (READ, WRITE, LOCK, | | | Return value for operations. |
| | COMMIT). | | offset4 | typedef uint64_t offset4; |
| qop4 | typedef uint32_t qop4; | | | Various offset designations (READ, WRITE, |
| | Quality of protection designation in SECINFO. | | | LOCK, COMMIT). |
| sec_oid4 | typedef opaque sec_oid4<>; | | qop4 | typedef uint32_t qop4; |
| | Security Object Identifier. The sec_oid4 data | | | Quality of protection designation in |
| | type is not really opaque. Instead it contains | | | SECINFO. |
| | an ASN.1 OBJECT IDENTIFIER as used by GSS-API in | | sec_oid4 | typedef opaque sec_oid4<>; |
| | the mech_type argument to GSS_Init_sec_context. | | | Security Object Identifier. The sec_oid4 |
| | See [6] for details. | | | data type is not really opaque. Instead |
| seqid4 | typedef uint32_t seqid4; | | | it contains an ASN.1 OBJECT IDENTIFIER as |
| | Sequence identifier used for file locking. | | | used by GSS-API in the mech_type argument |
| utf8string | typedef opaque utf8string<>; | | | to GSS_Init_sec_context. See [6] for |
| | UTF-8 encoding for strings. | | | details. |
| utf8_should | typedef utf8string utf8_should; | | seqid4 | typedef uint32_t seqid4; |
| | String expected to be UTF8 but no validation | | | Sequence identifier used for file locking. |
| utf8val_should | typedef utf8string utf8val_should; | | utf8string | typedef opaque utf8string<>; |
| | String SHOULD be sent UTF8 and SHOULD be | | | UTF-8 encoding for strings. |
| | validated | | utf8_expected | typedef utf8string utf8_expected; |
| utf8val_must | typedef utf8string utf8val_must; | | | String expected to be UTF-8 but no |
| | String MUST be sent UTF8 and MUST be validated | | | validation |
| ascii_must | typedef utf8string ascii_must; | | utf8val_RECOMMENDED4 | typedef utf8string utf8val_RECOMMENDED4; |
| | String MUST be sent as ASCII and thus is | | | String SHOULD be sent UTF-8 and SHOULD be |
| | automatically UTF8 | | | validated |
| comptag4 | typedef utf8_should comptag4; | | utf8val_REQUIRED4 | typedef utf8string utf8val_REQUIRED4; |
| | Tag should be UTF8 but is not checked | | | String MUST be sent UTF-8 and MUST be |
| component4 | typedef utf8val_should component4; | | | validated |
| | Represents path name components. | | ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |
| linktext4 | typedef utf8val_should linktext4; | | | String MUST be sent as ASCII and thus is |
| | Symbolic link contents. | | | automatically UTF.8 |
| pathname4 | typedef component4 pathname4<>; | | comptag4 | typedef utf8_expected comptag4; |
| | Represents path name for fs_locations. | | | Tag should be UTF.8 but is not checked |
| nfs_lockid4 | typedef uint64_t nfs_lockid4; | | component4 | typedef utf8val_RECOMMENDED4 component4; |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; | | | Represents path name components. |
| | Verifier used for various operations (COMMIT, | | linktext4 | typedef utf8val_RECOMMENDED4 linktext4; |
| | CREATE, EXCHANGE_ID, OPEN, READDIR, WRITE) | | | Symbolic link contents. |
| | NFS4_VERIFIER_SIZE is defined as 8. | | pathname4 | typedef component4 pathname4<>; |
+----------------+--------------------------------------------------+ | | Represents path name for fs_locations. |
| nfs_lockid4 | typedef uint64_t nfs_lockid4; |
| verifier4 | typedef opaque |
| | verifier4[NFS4_VERIFIER_SIZE]; |
| | Verifier used for various operations |
| | (COMMIT, CREATE, EXCHANGE_ID, OPEN, |
| | READDIR, WRITE) NFS4_VERIFIER_SIZE is |
| | defined as 8. |
+----------------------+--------------------------------------------+
End of Base Data Types End of Base Data Types
Table 1 Table 1
2.2. Structured Data Types 2.2. Structured Data Types
2.2.1. nfstime4 2.2.1. nfstime4
struct nfstime4 { struct nfstime4 {
skipping to change at page 21, line 41 skipping to change at page 21, line 41
uint64_t major; uint64_t major;
uint64_t minor; uint64_t minor;
}; };
This type is the filesystem identifier that is used as a mandatory This type is the filesystem identifier that is used as a mandatory
attribute. attribute.
2.2.6. fs_location4 2.2.6. fs_location4
struct fs_location4 { struct fs_location4 {
utf8val_must server<>; utf8val_REQUIRED4 server<>;
pathname4 rootpath; pathname4 rootpath;
}; };
2.2.7. fs_locations4 2.2.7. fs_locations4
struct fs_locations4 { struct fs_locations4 {
pathname4 fs_root; pathname4 fs_root;
fs_location4 locations<>; fs_location4 locations<>;
}; };
The fs_location4 and fs_locations4 data types are used for the The fs_location4 and fs_locations4 data types are used for the
skipping to change at page 22, line 22 skipping to change at page 22, line 22
}; };
The fattr4 structure is used to represent file and directory The fattr4 structure is used to represent file and directory
attributes. attributes.
The bitmap is a counted array of 32 bit integers used to contain bit The bitmap is a counted array of 32 bit integers used to contain bit
values. The position of the integer in the array that contains bit n values. The position of the integer in the array that contains bit n
can be computed from the expression (n / 32) and its bit within that can be computed from the expression (n / 32) and its bit within that
integer is (n mod 32). integer is (n mod 32).
0 1 0 1
+-----------+-----------+-----------+-- +-----------+-----------+-----------+--
| count | 31 .. 0 | 63 .. 32 | | count | 31 .. 0 | 63 .. 32 |
+-----------+-----------+-----------+-- +-----------+-----------+-----------+--
2.2.9. change_info4 2.2.9. change_info4
struct change_info4 { struct change_info4 {
bool atomic; bool atomic;
changeid4 before; changeid4 before;
changeid4 after; changeid4 after;
}; };
This structure is used with the CREATE, LINK, REMOVE, RENAME This structure is used with the CREATE, LINK, REMOVE, RENAME
skipping to change at page 22, line 50 skipping to change at page 22, line 50
struct clientaddr4 { struct clientaddr4 {
/* see struct rpcb in RFC 1833 */ /* see struct rpcb in RFC 1833 */
string r_netid<>; /* network id */ string r_netid<>; /* network id */
string r_addr<>; /* universal address */ string r_addr<>; /* universal address */
}; };
The clientaddr4 structure is used as part of the SETCLIENTID The clientaddr4 structure is used as part of the SETCLIENTID
operation to either specify the address of the client that is using a operation to either specify the address of the client that is using a
client ID or as part of the callback registration. The r_netid and client ID or as part of the callback registration. The r_netid and
r_addr fields are specified in [17], but they are underspecified in r_addr fields are specified in [16], but they are underspecified in
[17] as far as what they should look like for specific protocols. [16] as far as what they should look like for specific protocols.
For TCP over IPv4 and for UDP over IPv4, the format of r_addr is the For TCP over IPv4 and for UDP over IPv4, the format of r_addr is the
US-ASCII string: US-ASCII string:
h1.h2.h3.h4.p1.p2 h1.h2.h3.h4.p1.p2
The prefix, "h1.h2.h3.h4", is the standard textual form for The prefix, "h1.h2.h3.h4", is the standard textual form for
representing an IPv4 address, which is always four octets long. representing an IPv4 address, which is always four octets long.
Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
the first through fourth octets each converted to ASCII-decimal. the first through fourth octets each converted to ASCII-decimal.
Assuming big-endian ordering, p1 and p2 are, respectively, the first Assuming big-endian ordering, p1 and p2 are, respectively, the first
and second octets each converted to ASCII-decimal. For example, if a and second octets each converted to ASCII-decimal. For example, if a
host, in big-endian order, has an address of 0x0A010307 and there is host, in big-endian order, has an address of 0x0A010307 and there is
a service listening on, in big endian order, port 0x020F (decimal a service listening on, in big endian order, port 0x020F (decimal
527), then the complete universal address is "10.1.3.7.2.15". 527), then the complete universal address is "10.1.3.7.2.15".
For TCP over IPv4 the value of r_netid is the string "tcp". For UDP For TCP over IPv4 the value of r_netid is the string "tcp". For UDP
over IPv4 the value of r_netid is the string "udp". over IPv4 the value of r_netid is the string "udp".
For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the For TCP over IPv6 and for UDP over IPv6, the format of r_addr is the
US-ASCII string: US-ASCII string:
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
The suffix "p1.p2" is the service port, and is computed the same way The suffix "p1.p2" is the service port, and is computed the same way
as with universal addresses for TCP and UDP over IPv4. The prefix, as with universal addresses for TCP and UDP over IPv4. The prefix,
"x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form for "x1:x2:x3:x4:x5:x6:x7:x8", is the standard textual form for
representing an IPv6 address as defined in Section 2.2 of [18]. representing an IPv6 address as defined in Section 2.2 of [17].
Additionally, the two alternative forms specified in Section 2.2 of Additionally, the two alternative forms specified in Section 2.2 of
[18] are also acceptable. [17] are also acceptable.
For TCP over IPv6 the value of r_netid is the string "tcp6". For UDP For TCP over IPv6 the value of r_netid is the string "tcp6". For UDP
over IPv6 the value of r_netid is the string "udp6". over IPv6 the value of r_netid is the string "udp6".
2.2.11. cb_client4 2.2.11. cb_client4
struct cb_client4 { struct cb_client4 {
unsigned int cb_program; unsigned int cb_program;
clientaddr4 cb_location; clientaddr4 cb_location;
}; };
skipping to change at page 25, line 24 skipping to change at page 25, line 24
is read-only. The starting value of the seqid field is undefined. is read-only. The starting value of the seqid field is undefined.
The server is required to increment the seqid field monotonically at The server is required to increment the seqid field monotonically at
each transition of the stateid. This is important since the client each transition of the stateid. This is important since the client
will inspect the seqid in OPEN stateids to determine the order of will inspect the seqid in OPEN stateids to determine the order of
OPEN processing done by the server. OPEN processing done by the server.
3. RPC and Security Flavor 3. RPC and Security Flavor
The NFSv4 protocol is a Remote Procedure Call (RPC) application that The NFSv4 protocol is a Remote Procedure Call (RPC) application that
uses RPC version 2 and the corresponding eXternal Data Representation uses RPC version 2 and the corresponding eXternal Data Representation
(XDR) as defined in [3] and [15]. The RPCSEC_GSS security flavor as (XDR) as defined in [4] and [14]. The RPCSEC_GSS security flavor as
defined in [4] MUST be used as the mechanism to deliver stronger defined in [5] MUST be implemented as the mechanism to deliver
security for the NFSv4 protocol. stronger security for the NFSv4 protocol. However, deployment of
RPCSEC_GSS is optional.
3.1. Ports and Transports 3.1. Ports and Transports
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The Historically, NFSv2 and NFSv3 servers have resided on port 2049. The
registered port 2049 [19] for the NFS protocol SHOULD be the default registered port 2049 [18] for the NFS protocol SHOULD be the default
configuration. Using the registered port for NFS services means the configuration. Using the registered port for NFS services means the
NFS client will not need to use the RPC binding protocols as NFS client will not need to use the RPC binding protocols as
described in [17]; this will allow NFS to transit firewalls. described in [16]; this will allow NFS to transit firewalls.
Where an NFSv4 implementation supports operation over the IP network Where an NFSv4 implementation supports operation over the IP network
protocol, the supported transports between NFS and IP MUST be among protocol, the supported transports between NFS and IP MUST be among
the IETF-approved congestion control transport protocols, which the IETF-approved congestion control transport protocols, which
include TCP and SCTP. To enhance the possibilities for include TCP and SCTP. To enhance the possibilities for
interoperability, an NFSv4 implementation MUST support operation over interoperability, an NFSv4 implementation MUST support operation over
the TCP transport protocol, at least until such time as a standards the TCP transport protocol, at least until such time as a standards
track RFC revises this requirement to use a different IETF-approved track RFC revises this requirement to use a different IETF-approved
congestion control transport protocol. congestion control transport protocol.
skipping to change at page 26, line 21 skipping to change at page 26, line 23
AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS AUTH_SYS, AUTH_DH, RPCSEC_GSS or any other flavor. Similarly, NFS
over TCP server implementations have assumed such a model and thus over TCP server implementations have assumed such a model and thus
scale the implementation of TCP connection management in proportion scale the implementation of TCP connection management in proportion
to the number of expected client machines. It is intended that NFSv4 to the number of expected client machines. It is intended that NFSv4
will not modify this connection management model. NFSv4 clients that will not modify this connection management model. NFSv4 clients that
violate this assumption can expect scaling issues on the server and violate this assumption can expect scaling issues on the server and
hence reduced service. hence reduced service.
Note that for various timers, the client and server should avoid Note that for various timers, the client and server should avoid
inadvertent synchronization of those timers. For further discussion inadvertent synchronization of those timers. For further discussion
of the general issue refer to [20]. of the general issue refer to [19].
3.1.1. Client Retransmission Behavior 3.1.1. Client Retransmission Behavior
When processing a request received over a reliable transport such as When processing a request received over a reliable transport such as
TCP, the NFSv4 server MUST NOT silently drop the request, except if TCP, the NFSv4 server MUST NOT silently drop the request, except if
the transport connection has been broken. Given such a contract the transport connection has been broken. Given such a contract
between NFSv4 clients and servers, clients MUST NOT retry a request between NFSv4 clients and servers, clients MUST NOT retry a request
unless one or both of the following are true: unless one or both of the following are true:
o The transport connection has been broken o The transport connection has been broken
skipping to change at page 27, line 10 skipping to change at page 27, line 12
or it can break the transport connection and reconnect before re- or it can break the transport connection and reconnect before re-
sending the original request. sending the original request.
For callbacks from the server to the client, the same rules apply, For callbacks from the server to the client, the same rules apply,
but the server doing the callback becomes the client, and the client but the server doing the callback becomes the client, and the client
receiving the callback becomes the server. receiving the callback becomes the server.
3.2. Security Flavors 3.2. Security Flavors
Traditional RPC implementations have included AUTH_NONE, AUTH_SYS, Traditional RPC implementations have included AUTH_NONE, AUTH_SYS,
AUTH_DH, and AUTH_KRB4 as security flavors. With [4] an additional AUTH_DH, and AUTH_KRB4 as security flavors. With [5] an additional
security flavor of RPCSEC_GSS has been introduced which uses the security flavor of RPCSEC_GSS has been introduced which uses the
functionality of GSS-API [6]. This allows for the use of various functionality of GSS-API [6]. This allows for the use of various
security mechanisms by the RPC layer without the additional security mechanisms by the RPC layer without the additional
implementation overhead of adding RPC security flavors. For NFSv4, implementation overhead of adding RPC security flavors. For NFSv4,
the RPCSEC_GSS security flavor MUST be used to enable the mandatory the RPCSEC_GSS security flavor MUST be used to enable the mandatory
security mechanism. Other flavors, such as, AUTH_NONE, AUTH_SYS, and security mechanism. Other flavors, such as, AUTH_NONE, AUTH_SYS, and
AUTH_DH MAY be implemented as well. AUTH_DH MAY be implemented as well.
3.2.1. Security mechanisms for NFSv4 3.2.1. Security mechanisms for NFSv4
The use of RPCSEC_GSS requires selection of: mechanism, quality of The use of RPCSEC_GSS requires selection of: mechanism, quality of
protection, and service (authentication, integrity, privacy). The protection, and service (authentication, integrity, privacy). The
remainder of this document will refer to these three parameters of remainder of this document will refer to these three parameters of
the RPCSEC_GSS security as the security triple. the RPCSEC_GSS security as the security triple.
3.2.1.1. Kerberos V5 as a security triple 3.2.1.1. Kerberos V5 as a security triple
The Kerberos V5 GSS-API mechanism as described in [16] MUST be The Kerberos V5 GSS-API mechanism as described in [15] MUST be
implemented and provide the following security triples. implemented and provide the following security triples.
column descriptions: column descriptions:
1 == number of pseudo flavor 1 == number of pseudo flavor
2 == name of pseudo flavor 2 == name of pseudo flavor
3 == mechanism's OID 3 == mechanism's OID
4 == mechanism's algorithm(s) 4 == mechanism's algorithm(s)
5 == RPCSEC_GSS service 5 == RPCSEC_GSS service
skipping to change at page 28, line 8 skipping to change at page 28, line 9
and 56 bit DES and 56 bit DES
for privacy. for privacy.
Note that the pseudo flavor is presented here as a mapping aid to the Note that the pseudo flavor is presented here as a mapping aid to the
implementor. Because this NFS protocol includes a method to implementor. Because this NFS protocol includes a method to
negotiate security and it understands the GSS-API mechanism, the negotiate security and it understands the GSS-API mechanism, the
pseudo flavor is not needed. The pseudo flavor is needed for NFSv3 pseudo flavor is not needed. The pseudo flavor is needed for NFSv3
since the security negotiation is done via the MOUNT protocol. since the security negotiation is done via the MOUNT protocol.
For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please For a discussion of NFS' use of RPCSEC_GSS and Kerberos V5, please
see [21]. see [20].
Users and implementors are warned that 56 bit DES is no longer Users and implementors are warned that 56 bit DES is no longer
considered state of the art in terms of resistance to brute force considered state of the art in terms of resistance to brute force
attacks. Once a revision to [16] is available that adds support for attacks. Once a revision to [15] is available that adds support for
AES, implementors are urged to incorporate AES into their NFSv4 over AES, implementors are urged to incorporate AES into their NFSv4 over
Kerberos V5 protocol stacks, and users are similarly urged to migrate Kerberos V5 protocol stacks, and users are similarly urged to migrate
to the use of AES. to the use of AES.
3.2.1.2. LIPKEY as a security triple
The LIPKEY GSS-API mechanism as described in [5] MAY be implemented
and provide the following security triples. The definition of the
columns matches those in Section 3.2.1.1.
1 2 3 4 5
--------------------------------------------------------------------
390006 lipkey 1.3.6.1.5.5.9 negotiated rpc_gss_svc_none
390007 lipkey-i 1.3.6.1.5.5.9 negotiated rpc_gss_svc_integrity
390008 lipkey-p 1.3.6.1.5.5.9 negotiated rpc_gss_svc_privacy
The mechanism algorithm is listed as "negotiated". This is because
LIPKEY is layered on SPKM-3 and in SPKM-3 [5] the confidentiality and
integrity algorithms are negotiated. Since SPKM-3 specifies HMAC-MD5
for integrity as MANDATORY, 128 bit cast5CBC for confidentiality for
privacy as MANDATORY, and further specifies that HMAC-MD5 and
cast5CBC MUST be listed first before weaker algorithms, specifying
"negotiated" in column 4 does not impair interoperability. In the
event an SPKM-3 peer does not support the mandatory algorithms, the
other peer is free to accept or reject the GSS-API context creation.
Because SPKM-3 negotiates the algorithms, subsequent calls to
LIPKEY's GSS_Wrap() and GSS_GetMIC() by RPCSEC_GSS will use a quality
of protection value of 0 (zero). See section 5.2 of [22] for an
explanation.
LIPKEY uses SPKM-3 to create a secure channel in which to pass a user
name and password from the client to the server. Once the user name
and password have been accepted by the server, calls to the LIPKEY
context are redirected to the SPKM-3 context. See [5] for more
details.
3.2.1.3. SPKM-3 as a security triple
The SPKM-3 GSS-API mechanism as described in [5] MAY be implemented
and provide the following security triples. The definition of the
columns matches those in Section 3.2.1.1.
1 2 3 4 5
--------------------------------------------------------------------
390009 spkm3 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_none
390010 spkm3i 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_integrity
390011 spkm3p 1.3.6.1.5.5.1.3 negotiated rpc_gss_svc_privacy
For a discussion as to why the mechanism algorithm is listed as
"negotiated", see Section 3.2.1.2.
Because SPKM-3 negotiates the algorithms, subsequent calls to
SPKM-3's GSS_Wrap() and GSS_GetMIC() by RPCSEC_GSS will use a quality
of protection value of 0 (zero). See section 5.2 of [22] for an
explanation.
Even though LIPKEY is layered over SPKM-3, SPKM-3 is specified as a
mandatory set of triples to handle the situations where the initiator
(the client) is anonymous or where the initiator has its own
certificate. If the initiator is anonymous, there will not be a user
name and password to send to the target (the server). If the
initiator has its own certificate, then using passwords is
superfluous.
3.3. Security Negotiation 3.3. Security Negotiation
With the NFSv4 server potentially offering multiple security With the NFSv4 server potentially offering multiple security
mechanisms, the client needs a method to determine or negotiate which mechanisms, the client needs a method to determine or negotiate which
mechanism is to be used for its communication with the server. The mechanism is to be used for its communication with the server. The
NFS server may have multiple points within its filesystem name space NFS server may have multiple points within its filesystem name space
that are available for use by NFS clients. In turn the NFS server that are available for use by NFS clients. In turn the NFS server
may be configured such that each of these entry points may have may be configured such that each of these entry points may have
different or multiple security mechanisms in use. different or multiple security mechanisms in use.
skipping to change at page 30, line 18 skipping to change at page 28, line 47
per filehandle basis, what security triple is to be used for server per filehandle basis, what security triple is to be used for server
access. In general, the client will not have to use the SECINFO access. In general, the client will not have to use the SECINFO
operation except during initial communication with the server or when operation except during initial communication with the server or when
the client crosses policy boundaries at the server. It is possible the client crosses policy boundaries at the server. It is possible
that the server's policies change during the client's interaction that the server's policies change during the client's interaction
therefore forcing the client to negotiate a new security triple. therefore forcing the client to negotiate a new security triple.
3.3.2. Security Error 3.3.2. Security Error
Based on the assumption that each NFSv4 client and server MUST Based on the assumption that each NFSv4 client and server MUST
support a minimum set of security (i.e., LIPKEY, SPKM-3, and support a minimum set of security (i.e., Kerberos-V5 under
Kerberos-V5 all under RPCSEC_GSS), the NFS client will start its RPCSEC_GSS), the NFS client will start its communication with the
communication with the server with one of the minimal security server with one of the minimal security triples. During
triples. During communication with the server, the client may communication with the server, the client may receive an NFS error of
receive an NFS error of NFS4ERR_WRONGSEC. This error allows the NFS4ERR_WRONGSEC. This error allows the server to notify the client
server to notify the client that the security triple currently being that the security triple currently being used is not appropriate for
used is not appropriate for access to the server's filesystem access to the server's filesystem resources. The client is then
resources. The client is then responsible for determining what responsible for determining what security triples are available at
security triples are available at the server and choose one which is the server and choose one which is appropriate for the client. See
appropriate for the client. See Section 15.33 for further discussion Section 15.33 for further discussion of how the client will respond
of how the client will respond to the NFS4ERR_WRONGSEC error and use to the NFS4ERR_WRONGSEC error and use SECINFO.
SECINFO.
3.3.3. Callback RPC Authentication 3.3.3. Callback RPC Authentication
Except as noted elsewhere in this section, the callback RPC Except as noted elsewhere in this section, the callback RPC
(described later) MUST mutually authenticate the NFS server to the (described later) MUST mutually authenticate the NFS server to the
principal that acquired the client ID (also described later), using principal that acquired the client ID (also described later), using
the security flavor the original SETCLIENTID operation used. the security flavor the original SETCLIENTID operation used.
For AUTH_NONE, there are no principals, so this is a non-issue. For AUTH_NONE, there are no principals, so this is a non-issue.
AUTH_SYS has no notions of mutual authentication or a server AUTH_SYS has no notions of mutual authentication or a server
principal, so the callback from the server simply uses the AUTH_SYS principal, so the callback from the server simply uses the AUTH_SYS
credential that the user used when he set up the delegation. credential that the user used when he set up the delegation.
For AUTH_DH, one commonly used convention is that the server uses the For AUTH_DH, one commonly used convention is that the server uses the
credential corresponding to this AUTH_DH principal: credential corresponding to this AUTH_DH principal:
unix.host@domain unix.host@domain
where host and domain are variables corresponding to the name of where host and domain are variables corresponding to the name of
server host and directory services domain in which it lives such as a server host and directory services domain in which it lives such as a
Network Information System domain or a DNS domain. Network Information System domain or a DNS domain.
Because LIPKEY is layered over SPKM-3, it is permissible for the
server to use SPKM-3 and not LIPKEY for the callback even if the
client used LIPKEY for SETCLIENTID.
Regardless of what security mechanism under RPCSEC_GSS is being used, Regardless of what security mechanism under RPCSEC_GSS is being used,
the NFS server, MUST identify itself in GSS-API via a the NFS server, MUST identify itself in GSS-API via a
GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE
names are of the form: names are of the form:
service@hostname service@hostname
For NFS, the "service" element is For NFS, the "service" element is
nfs nfs
Implementations of security mechanisms will convert nfs@hostname to Implementations of security mechanisms will convert nfs@hostname to
various different forms. For Kerberos V5 and LIPKEY, the following various different forms. For Kerberos V5, the following form is
form is RECOMMENDED: RECOMMENDED:
nfs/hostname nfs/hostname
For Kerberos V5, nfs/hostname would be a server principal in the For Kerberos V5, nfs/hostname would be a server principal in the
Kerberos Key Distribution Center database. This is the same Kerberos Key Distribution Center database. This is the same
principal the client acquired a GSS-API context for when it issued principal the client acquired a GSS-API context for when it issued
the SETCLIENTID operation, therefore, the realm name for the server the SETCLIENTID operation, therefore, the realm name for the server
principal must be the same for the callback as it was for the principal must be the same for the callback as it was for the
SETCLIENTID. SETCLIENTID.
For LIPKEY, this would be the username passed to the target (the NFS
version 4 client that receives the callback).
It should be noted that LIPKEY may not work for callbacks, since the
LIPKEY client uses a user id/password. If the NFS client receiving
the callback can authenticate the NFS server's user name/password
pair, and if the user that the NFS server is authenticating to has a
public key certificate, then it works.
In situations where the NFS client uses LIPKEY and uses a per-host
principal for the SETCLIENTID operation, instead of using LIPKEY for
SETCLIENTID, it is RECOMMENDED that SPKM-3 with mutual authentication
be used. This effectively means that the client will use a
certificate to authenticate and identify the initiator to the target
on the NFS server. Using SPKM-3 and not LIPKEY has the following
advantages:
o When the server does a callback, it must authenticate to the
principal used in the SETCLIENTID. Even if LIPKEY is used,
because LIPKEY is layered over SPKM-3, the NFS client will need to
have a certificate that corresponds to the principal used in the
SETCLIENTID operation. From an administrative perspective, having
a user name, password, and certificate for both the client and
server is redundant.
o LIPKEY was intended to minimize additional infrastructure
requirements beyond a certificate for the target, and the
expectation is that existing password infrastructure can be
leveraged for the initiator. In some environments, a per-host
password does not exist yet. If certificates are used for any
per-host principals, then additional password infrastructure is
not needed.
o In cases when a host is both an NFS client and server, it can
share the same per-host certificate.
4. Filehandles 4. Filehandles
The filehandle in the NFS protocol is a per server unique identifier The filehandle in the NFS protocol is a per server unique identifier
for a filesystem object. The contents of the filehandle are opaque for a filesystem object. The contents of the filehandle are opaque
to the client. Therefore, the server is responsible for translating to the client. Therefore, the server is responsible for translating
the filehandle to an internal representation of the filesystem the filehandle to an internal representation of the filesystem
object. object.
4.1. Obtaining the First Filehandle 4.1. Obtaining the First Filehandle
The operations of the NFS protocol are defined in terms of one or The operations of the NFS protocol are defined in terms of one or
more filehandles. Therefore, the client needs a filehandle to more filehandles. Therefore, the client needs a filehandle to
initiate communication with the server. With the NFSv2 protocol [13] initiate communication with the server. With the NFSv2 protocol [12]
and the NFSv3 protocol [14], there exists an ancillary protocol to and the NFSv3 protocol [13], there exists an ancillary protocol to
obtain this first filehandle. The MOUNT protocol, RPC program number obtain this first filehandle. The MOUNT protocol, RPC program number
100005, provides the mechanism of translating a string based 100005, provides the mechanism of translating a string based
filesystem path name to a filehandle which can then be used by the filesystem path name to a filehandle which can then be used by the
NFS protocols. NFS protocols.
The MOUNT protocol has deficiencies in the area of security and use The MOUNT protocol has deficiencies in the area of security and use
via firewalls. This is one reason that the use of the public via firewalls. This is one reason that the use of the public
filehandle was introduced in [23] and [24]. With the use of the filehandle was introduced in [21] and [22]. With the use of the
public filehandle in combination with the LOOKUP operation in the public filehandle in combination with the LOOKUP operation in the
NFSv2 and NFSv3 protocols, it has been demonstrated that the MOUNT NFSv2 and NFSv3 protocols, it has been demonstrated that the MOUNT
protocol is unnecessary for viable interaction between NFS client and protocol is unnecessary for viable interaction between NFS client and
server. server.
Therefore, the NFSv4 protocol will not use an ancillary protocol for Therefore, the NFSv4 protocol will not use an ancillary protocol for
translation from string based path names to a filehandle. Two translation from string based path names to a filehandle. Two
special filehandles will be used as starting points for the NFS special filehandles will be used as starting points for the NFS
client. client.
skipping to change at page 36, line 23 skipping to change at page 34, line 13
open), FH4_VOLATILE_ANY (in this case with FH4_NOEXPIRE_WITH_OPEN) is open), FH4_VOLATILE_ANY (in this case with FH4_NOEXPIRE_WITH_OPEN) is
a better choice since the client may not assume that all filehandles a better choice since the client may not assume that all filehandles
will expire when migration occurs, and it is likely that additional will expire when migration occurs, and it is likely that additional
expirations will occur (as a result of file CLOSE) that are separated expirations will occur (as a result of file CLOSE) that are separated
in time from the migration event itself. in time from the migration event itself.
4.2.4. One Method of Constructing a Volatile Filehandle 4.2.4. One Method of Constructing a Volatile Filehandle
A volatile filehandle, while opaque to the client could contain: A volatile filehandle, while opaque to the client could contain:
[volatile bit = 1 | server boot time | slot | generation number] [volatile bit = 1 | server boot time | slot | generation number]
o slot is an index in the server volatile filehandle table o slot is an index in the server volatile filehandle table
o generation number is the generation number for the table entry/ o generation number is the generation number for the table entry/
slot slot
When the client presents a volatile filehandle, the server makes the When the client presents a volatile filehandle, the server makes the
following checks, which assume that the check for the volatile bit following checks, which assume that the check for the volatile bit
has passed. If the server boot time is less than the current server has passed. If the server boot time is less than the current server
boot time, return NFS4ERR_FHEXPIRED. If slot is out of range, return boot time, return NFS4ERR_FHEXPIRED. If slot is out of range, return
skipping to change at page 37, line 24 skipping to change at page 35, line 14
has been renamed. If the file was renamed by another client, again has been renamed. If the file was renamed by another client, again
it is possible that the original client will not be able to recover. it is possible that the original client will not be able to recover.
However, in the case that the client itself is renaming the file and However, in the case that the client itself is renaming the file and
the file is open, it is possible that the client may be able to the file is open, it is possible that the client may be able to
recover. The client can determine the new path name based on the recover. The client can determine the new path name based on the
processing of the rename request. The client can then regenerate the processing of the rename request. The client can then regenerate the
new filehandle based on the new path name. The client could also use new filehandle based on the new path name. The client could also use
the compound operation mechanism to construct a set of operations the compound operation mechanism to construct a set of operations
like: like:
RENAME A B RENAME A B
LOOKUP B LOOKUP B
GETFH GETFH
Note that the COMPOUND procedure does not provide atomicity. This Note that the COMPOUND procedure does not provide atomicity. This
example only reduces the overhead of recovering from an expired example only reduces the overhead of recovering from an expired
filehandle. filehandle.
5. File Attributes 5. File Attributes
To meet the requirements of extensibility and increased To meet the requirements of extensibility and increased
interoperability with non-UNIX platforms, attributes need to be interoperability with non-UNIX platforms, attributes need to be
handled in a flexible manner. The NFSv3 fattr3 structure contains a handled in a flexible manner. The NFSv3 fattr3 structure contains a
skipping to change at page 40, line 9 skipping to change at page 37, line 47
normal READ and WRITE operations using the filehandles and stateids normal READ and WRITE operations using the filehandles and stateids
returned by OPEN. returned by OPEN.
Named attributes and the named attribute directory may have their own Named attributes and the named attribute directory may have their own
(non-named) attributes. Each of these objects must have all of the (non-named) attributes. Each of these objects must have all of the
REQUIRED attributes and may have additional RECOMMENDED attributes. REQUIRED attributes and may have additional RECOMMENDED attributes.
However, the set of attributes for named attributes and the named However, the set of attributes for named attributes and the named
attribute directory need not be, and typically will not be, as large attribute directory need not be, and typically will not be, as large
as that for other objects in that file system. as that for other objects in that file system.
Named attributes and the named attribute directory might be the Named attributes might be the target of delegations. However, since
target of delegations (in the case of the named attribute directory granting of delegations is at the server's discretion, a server need
these will be directory delegations). However, since granting of not support delegations on named attributes.
delegations is at the server's discretion, a server need not support
delegations on named attributes or the named attribute directory.
It is RECOMMENDED that servers support arbitrary named attributes. A It is RECOMMENDED that servers support arbitrary named attributes. A
client should not depend on the ability to store any named attributes client should not depend on the ability to store any named attributes
in the server's file system. If a server does support named in the server's file system. If a server does support named
attributes, a client that is also able to handle them should be able attributes, a client that is also able to handle them should be able
to copy a file's data and metadata with complete transparency from to copy a file's data and metadata with complete transparency from
one location to another; this would imply that names allowed for one location to another; this would imply that names allowed for
regular directory entries are valid for named attribute names as regular directory entries are valid for named attribute names as
well. well.
skipping to change at page 42, line 16 skipping to change at page 40, line 5
5.6. REQUIRED Attributes - List and Definition References 5.6. REQUIRED Attributes - List and Definition References
The list of REQUIRED attributes appears in Table 2. The meaning of The list of REQUIRED attributes appears in Table 2. The meaning of
the columns of the table are: the 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 [2], the latter is conflicts between the assigned number and [2], the latter is
likely authoritative, but should be resolved with Errata to this likely authoritative, but should be resolved with Errata to this
document and/or [2]. See [25] for the Errata process. document and/or [2]. See [23] for the Errata process.
o Data Type: The XDR data type of the attribute. o Data Type: The XDR data type of the attribute.
o Acc: Access allowed to the attribute. R means read-only (GETATTR o Acc: Access allowed to the attribute. R means read-only (GETATTR
may retrieve, SETATTR may not set). W means write-only (SETATTR may retrieve, SETATTR may not set). W means write-only (SETATTR
may set, GETATTR may not retrieve). R W means read/write (GETATTR may set, GETATTR may not retrieve). R W means read/write (GETATTR
may retrieve, SETATTR may set). 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.
skipping to change at page 45, line 8 skipping to change at page 42, line 42
Within the explanatory text and operation descriptions, the following Within the explanatory text and operation descriptions, the following
phrases will be used with the meanings given below: phrases will be used with the meanings given below:
o The phrase "is a directory" means that the object's type attribute o The phrase "is a directory" means that the object's type attribute
is NF4DIR or NF4ATTRDIR. is NF4DIR or NF4ATTRDIR.
o The phrase "is a special file" means that the object's type o The phrase "is a special file" means that the object's type
attribute is NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO. attribute is NF4BLK, NF4CHR, NF4SOCK, or NF4FIFO.
o The phrase "is an ordinary file" means that the object's type o The phrase "is an regular file" means that the object's type
attribute is NF4REG or NF4NAMEDATTR. attribute is NF4REG or NF4NAMEDATTR.
5.8.1.3. Attribute 2: fh_expire_type 5.8.1.3. Attribute 2: fh_expire_type
Server uses this to specify filehandle expiration behavior to the Server uses this to specify filehandle expiration behavior to the
client. See Section 4 for additional description. client. See Section 4 for additional description.
5.8.1.4. Attribute 3: change 5.8.1.4. Attribute 3: change
A value created by the server that the client can use to determine if A value created by the server that the client can use to determine if
skipping to change at page 51, line 32 skipping to change at page 49, line 23
5.8.2.33. Attribute 47: time_access 5.8.2.33. Attribute 47: time_access
The time_access attribute represents the time of last access to the The time_access attribute represents the time of last access to the
object by a READ operation sent to the server. The notion of what is object by a READ operation sent to the server. The notion of what is
an "access" depends on the server's operating environment and/or the an "access" depends on the server's operating environment and/or the
server's file system semantics. For example, for servers obeying server's file system semantics. For example, for servers obeying
Portable Operating System Interface (POSIX) semantics, time_access Portable Operating System Interface (POSIX) semantics, time_access
would be updated only by the READ and READDIR operations and not any would be updated only by the READ and READDIR operations and not any
of the operations that modify the content of the object [16], [17], of the operations that modify the content of the object [16], [17],
[26], [27], [28]. Of course, setting the corresponding [24], [25], [26]. Of course, setting the corresponding
time_access_set attribute is another way to modify the time_access time_access_set attribute is another way to modify the time_access
attribute. attribute.
Whenever the file object resides on a writable file system, the Whenever the file object resides on a writable file system, the
server should make its best efforts to record time_access into stable server should make its best efforts to record time_access into stable
storage. However, to mitigate the performance effects of doing so, storage. However, to mitigate the performance effects of doing so,
and most especially whenever the server is satisfying the read of the and most especially whenever the server is satisfying the read of the
object's content from its cache, the server MAY cache access time object's content from its cache, the server MAY cache access time
updates and lazily write them to stable storage. It is also updates and lazily write them to stable storage. It is also
acceptable to give administrators of the server the option to disable acceptable to give administrators of the server the option to disable
skipping to change at page 52, line 33 skipping to change at page 50, line 27
5.8.2.40. Attribute 54: time_modify_set 5.8.2.40. Attribute 54: time_modify_set
Sets the time of last modification to the object. SETATTR use only. Sets the time of last modification to the object. SETATTR use only.
5.9. Interpreting owner and owner_group 5.9. Interpreting owner and owner_group
The RECOMMENDED attributes "owner" and "owner_group" (and also users The RECOMMENDED attributes "owner" and "owner_group" (and also users
and groups within the "acl" attribute) are represented in terms of a and groups within the "acl" attribute) are represented in terms of a
UTF-8 string. To avoid a representation that is tied to a particular UTF-8 string. To avoid a representation that is tied to a particular
underlying implementation at the client or server, the use of the underlying implementation at the client or server, the use of the
UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 [29] UTF-8 string has been chosen. Note that section 6.1 of RFC 2624 [27]
provides additional rationale. It is expected that the client and provides additional rationale. It is expected that the client and
server will have their own local representation of owner and server will have their own local representation of owner and
owner_group that is used for local storage or presentation to the end owner_group that is used for local storage or presentation to the end
user. Therefore, it is expected that when these attributes are user. Therefore, it is expected that when these attributes are
transferred between the client and server, the local representation transferred between the client and server, the local representation
is translated to a syntax of the form "user@dns_domain". This will is translated to a syntax of the form "user@dns_domain". This will
allow for a client and server that do not use the same local allow for a client and server that do not use the same local
representation the ability to translate to a common syntax that can representation the ability to translate to a common syntax that can
be interpreted by both. be interpreted by both.
skipping to change at page 54, line 13 skipping to change at page 52, line 7
Internationalization issues (for a general discussion of which see Internationalization issues (for a general discussion of which see
Section 12) make this impossible and the client needs to take note of Section 12) make this impossible and the client needs to take note of
the following situations: the following situations:
o The string representing the domain may be converted to equivalent o The string representing the domain may be converted to equivalent
U-label, if presented using a form other a a U-label. See U-label, if presented using a form other a a U-label. See
Section 12.6 for details. Section 12.6 for details.
o The user or group may be returned in a different form, due to o The user or group may be returned in a different form, due to
normalization issues, although it will always be a canonically normalization issues, although it will always be a canonically
equivalent string. See See Section 12.7.3 for details. equivalent string. See Section 12.7.3 for details.
In the case where there is no translation available to the client or In the case where there is no translation available to the client or
server, the attribute value will be constructed without the "@". server, the attribute value will be constructed without the "@".
Therefore, the absence of the "@" from the owner or owner_group Therefore, the absence of the "@" from the owner or owner_group
attribute signifies that no translation was available at the sender attribute signifies that no translation was available at the sender
and that the receiver of the attribute should not use that string as and that the receiver of the attribute should not use that string as
a basis for translation into its own internal format. Even though a basis for translation into its own internal format. Even though
the attribute value cannot be translated, it may still be useful. In the attribute value cannot be translated, it may still be useful. In
the case of a client, the attribute string may be used for local the case of a client, the attribute string may be used for local
display of ownership. display of ownership.
To provide a greater degree of compatibility with NFSv3, which To provide a greater degree of compatibility with NFSv3, which
identified users and groups by 32-bit unsigned user identifiers and identified users and groups by 32-bit unsigned user identifiers and
group identifiers, owner and group strings that consist of decimal group identifiers, owner and group strings that consist of ASCII-
numeric values with no leading zeros can be given a special encoded decimal numeric values with no leading zeros can be given a
interpretation by clients and servers that choose to provide such special interpretation by clients and servers that choose to provide
support. The receiver may treat such a user or group string as such support. The receiver may treat such a user or group string as
representing the same user as would be represented by an NFSv3 uid or representing the same user as would be represented by an NFSv3 uid or
gid having the corresponding numeric value. gid having the corresponding numeric value.
A server SHOULD reject such a numeric value if the security mechanism A server SHOULD reject such a numeric value if the security mechanism
is kerberized. I.e., in such a scenario, the client will already is kerberized. I.e., in such a scenario, the client will already
need to form "user@domain" strings. For any other security need to form "user@domain" strings. For any other security
mechanism, the server SHOULD accept such numeric values. As an mechanism, the server SHOULD accept such numeric values. As an
implementation note, the server could make such an acceptance be implementation note, the server could make such an acceptance be
configurable. If the server does not support numeric values or if it configurable. If the server does not support numeric values or if it
is configured off, then it MUST return an NFS4ERR_BADOWNER error. If is configured off, then it MUST return an NFS4ERR_BADOWNER error. If
the security mechanism is kerberized and the client attempts to use the security mechanism is kerberized and the client attempts to use
the special form, then the server SHOULD return an NFS4ERR_BADOWNER the special form, then the server SHOULD return an NFS4ERR_BADOWNER
error when there is a valid translation for the user or owner error when there is a valid translation for the user or owner
designated in this way. In that case, the client must use the designated in this way. In that case, the client must use the
appropriate user@domain string and not the special form for appropriate user@domain string and not the special form for
compatibility. compatibility.
The client MUST always accept numeric values if the security The client MUST always accept numeric values if the security
mechanism is not kerberized. A client can determine if a server mechanism is not RPCSEC_GSS. A client can determine if a server
supports such a mechanism by first attempting to provide a numeric supports numeric identifiers by first attempting to provide a numeric
value and only if it is rejected with an NFS4ERR_BADOWNER error, then identifier. If this attempt rejected with an NFS4ERR_BADOWNER error,
providing a name value. After the first detection of such an error, the the client should only use named identifiers of the form "user@
the client should only use the special form. dns_domain".
The owner string "nobody" may be used to designate an anonymous user, The owner string "nobody" may be used to designate an anonymous user,
which will be associated with a file created by a security principal which will be associated with a file created by a security principal
that cannot be mapped through normal means to the owner attribute. that cannot be mapped through normal means to the owner attribute.
5.10. Character Case Attributes 5.10. Character Case Attributes
With respect to the case_insensitive and case_preserving attributes, With respect to the case_insensitive and case_preserving attributes,
each UCS-4 character (which UTF-8 encodes) has a "long descriptive each UCS-4 character (which UTF-8 encodes) has a "long descriptive
name" RFC1345 [30] which may or may not include the word "CAPITAL" or name" RFC1345 [28] which may or may not include the word "CAPITAL" or
"SMALL". The presence of SMALL or CAPITAL allows an NFS server to "SMALL". The presence of SMALL or CAPITAL allows an NFS server to
implement unambiguous and efficient table driven mappings for case implement unambiguous and efficient table driven mappings for case
insensitive comparisons, and non-case-preserving storage, although insensitive comparisons, and non-case-preserving storage, although
there are variations that occur additional characters with a name there are variations that occur additional characters with a name
including "SMALL" or "CAPITAL" are added in a subsequent version of including "SMALL" or "CAPITAL" are added in a subsequent version of
Unicode. Unicode.
For general character handling and internationalization issues, see For general character handling and internationalization issues, see
Section 12. For details regarding case mapping, see the section Section 12. For details regarding case mapping, see the section
Case-based Mapping Used for Component4 Strings. Case-based Mapping Used for Component4 Strings.
skipping to change at page 56, line 45 skipping to change at page 54, line 37
The NFS ACE structure is defined as follows: The NFS ACE structure is defined as follows:
typedef uint32_t acetype4; typedef uint32_t acetype4;
typedef uint32_t aceflag4; typedef uint32_t aceflag4;
typedef uint32_t acemask4; typedef uint32_t acemask4;
struct nfsace4 { struct nfsace4 {
acetype4 type; acetype4 type;
aceflag4 flag; aceflag4 flag;
acemask4 access_mask; acemask4 access_mask;
utf8val_must who; utf8val_REQUIRED4 who;
}; };
To determine if a request succeeds, the server processes each nfsace4 To determine if a request succeeds, the server processes each nfsace4
entry in order. Only ACEs which have a "who" that matches the entry in order. Only ACEs which have a "who" that matches the
requester are considered. Each ACE is processed until all of the requester are considered. Each ACE is processed until all of the
bits of the requester's access have been ALLOWED. Once a bit (see bits of the requester's access have been ALLOWED. Once a bit (see
below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer below) has been ALLOWED by an ACCESS_ALLOWED_ACE, it is no longer
considered in the processing of later ACEs. If an ACCESS_DENIED_ACE considered in the processing of later ACEs. If an ACCESS_DENIED_ACE
is encountered where the requester's access still has unALLOWED bits is encountered where the requester's access still has unALLOWED bits
in common with the "access_mask" of the ACE, the request is denied. in common with the "access_mask" of the ACE, the request is denied.
When the ACL is fully processed, if there are bits in the requester's When the ACL is fully processed, if there are bits in the requester's
mask that have not been ALLOWED or DENIED, access is denied. mask that have not been ALLOWED or DENIED, access is denied.
skipping to change at page 63, line 11 skipping to change at page 61, line 5
exists depends on the ability to look it up, therefore, users exists depends on the ability to look it up, therefore, users
also need the ACE4_READ_NAMED_ATTRS permission in order to also need the ACE4_READ_NAMED_ATTRS permission in order to
create a named attribute directory. create a named attribute directory.
ACE4_EXECUTE ACE4_EXECUTE
Operation(s) affected: Operation(s) affected:
READ READ
OPEN
REMOVE
RENAME
LINK
CREATE
Discussion: Discussion:
Permission to execute a file. Permission to execute a file.
Servers SHOULD allow a user the ability to read the data of the Servers SHOULD allow a user the ability to read the data of the
file when only the ACE4_EXECUTE access mask bit is allowed. file when only the ACE4_EXECUTE access mask bit is allowed.
This is because there is no way to execute a file without This is because there is no way to execute a file without
reading the contents. Though a server may treat ACE4_EXECUTE reading the contents. Though a server may treat ACE4_EXECUTE
and ACE4_READ_DATA bits identically when deciding to permit a and ACE4_READ_DATA bits identically when deciding to permit a
READ operation, it SHOULD still allow the two bits to be set READ operation, it SHOULD still allow the two bits to be set
skipping to change at page 64, line 11 skipping to change at page 61, line 39
Rather than: Rather than:
nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW nfsuser:ACE4_EXECUTE/ACE4_READ_DATA:ALLOW
ACE4_EXECUTE ACE4_EXECUTE
Operation(s) affected: Operation(s) affected:
LOOKUP LOOKUP
OPEN
REMOVE
RENAME
LINK
CREATE
Discussion: Discussion:
Permission to traverse/search a directory. Permission to traverse/search a directory.
ACE4_DELETE_CHILD ACE4_DELETE_CHILD
Operation(s) affected: Operation(s) affected:
REMOVE REMOVE
skipping to change at page 66, line 31 skipping to change at page 64, line 25
chgrp(). chgrp().
ACE4_SYNCHRONIZE ACE4_SYNCHRONIZE
Operation(s) affected: Operation(s) affected:
NONE NONE
Discussion: Discussion:
Permission to access file locally at the server with Permission to use the file object as a synchronization
synchronized reads and writes. primitive for interprocess communication. This permission is
not enforced or interpreted by the NFSv4.0 server on behalf of
the client.
Typically, the ACE4_SYNCHRONIZE permission is only meaningful
on local file systems, i.e., file systems not accessed via
NFSv4.0. The reason that the permission bit exists is that
some operating environments, such as Windows, use
ACE4_SYNCHRONIZE.
For example, if a client copies a file that has
ACE4_SYNCHRONIZE set from a local file system to an NFSv4.0
server, and then later copies the file from the NFSv4.0 server
to a local file system, it is likely that if ACE4_SYNCHRONIZE
was set in the original file, the client will want it set in
the second copy. The first copy will not have the permission
set unless the NFSv4.0 server has the means to set the
ACE4_SYNCHRONIZE bit. The second copy will not have the
permission set unless the NFSv4.0 server has the means to
retrieve the ACE4_SYNCHRONIZE bit.
Server implementations need not provide the granularity of control Server implementations need not provide the granularity of control
that is implied by this list of masks. For example, POSIX-based that is implied by this list of masks. For example, POSIX-based
systems might not distinguish ACE4_APPEND_DATA (the ability to append systems might not distinguish ACE4_APPEND_DATA (the ability to append
to a file) from ACE4_WRITE_DATA (the ability to modify existing to a file) from ACE4_WRITE_DATA (the ability to modify existing
contents); both masks would be tied to a single "write" permission. contents); both masks would be tied to a single "write" permission.
When such a server returns attributes to the client, it would show When such a server returns attributes to the client, it would show
both ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the write both ACE4_APPEND_DATA and ACE4_WRITE_DATA if and only if the write
permission is enabled. permission is enabled.
skipping to change at page 85, line 38 skipping to change at page 83, line 38
limit the changes seen by the client, to those that are less limit the changes seen by the client, to those that are less
aggressive, use more standard methods of replicating data, and impose aggressive, use more standard methods of replicating data, and impose
a greater burden on the client to adapt to the transition. a greater burden on the client to adapt to the transition.
The NFSv4 protocol does not impose choices on clients and servers The NFSv4 protocol does not impose choices on clients and servers
with regard to that spectrum of transition methods. In fact, there with regard to that spectrum of transition methods. In fact, there
are many valid choices, depending on client and application are many valid choices, depending on client and application
requirements and their interaction with server implementation requirements and their interaction with server implementation
choices. The NFSv4.0 protocol does not provide the servers a means choices. The NFSv4.0 protocol does not provide the servers a means
of communicating the transition methods. In the NFSv4.1 protocol of communicating the transition methods. In the NFSv4.1 protocol
[31], an additional attribute "fs_locations_info" is presented, which [29], an additional attribute "fs_locations_info" is presented, which
will define the specific choices that can be made, how these choices will define the specific choices that can be made, how these choices
are communicated to the client, and how the client is to deal with are communicated to the client, and how the client is to deal with
any discontinuities. any discontinuities.
In the sections below, references will be made to various possible In the sections below, references will be made to various possible
server implementation choices as a way of illustrating the transition server implementation choices as a way of illustrating the transition
scenarios that clients may deal with. The intent here is not to scenarios that clients may deal with. The intent here is not to
define or limit server implementations but rather to illustrate the define or limit server implementations but rather to illustrate the
range of issues that clients may face. Again, as the NFSv4.0 range of issues that clients may face. Again, as the NFSv4.0
protocol does not have an explicit means of communicating these protocol does not have an explicit means of communicating these
skipping to change at page 100, line 6 skipping to change at page 98, line 6
The attributes for entry "path" will not contain size or time_modify The attributes for entry "path" will not contain size or time_modify
because these attributes are not available within an absent file because these attributes are not available within an absent file
system. system.
7.9. The Attribute fs_locations 7.9. The Attribute fs_locations
The fs_locations attribute is structured in the following way: The fs_locations attribute is structured in the following way:
struct fs_location4 { struct fs_location4 {
utf8val_must server<>; utf8val_REQUIRED4 server<>;
pathname4 rootpath; pathname4 rootpath;
}; };
struct fs_locations4 { struct fs_locations4 {
pathname4 fs_root; pathname4 fs_root;
fs_location4 locations<>; fs_location4 locations<>;
}; };
The fs_location4 data type is used to represent the location of a The fs_location4 data type is used to represent the location of a
file system by providing a server name and the path to the root of file system by providing a server name and the path to the root of
the file system within that server's namespace. When a set of the file system within that server's namespace. When a set of
skipping to change at page 104, line 10 skipping to change at page 102, line 10
the exports within the framework of a single server name space. An the exports within the framework of a single server name space. An
NFSv4 client uses LOOKUP and READDIR operations to browse seamlessly NFSv4 client uses LOOKUP and READDIR operations to browse seamlessly
from one export to another. Portions of the server name space that from one export to another. Portions of the server name space that
are not exported are bridged via a "pseudo filesystem" that provides are not exported are bridged via a "pseudo filesystem" that provides
a view of exported directories only. A pseudo filesystem has a a view of exported directories only. A pseudo filesystem has a
unique fsid and behaves like a normal, read only filesystem. unique fsid and behaves like a normal, read only filesystem.
Based on the construction of the server's name space, it is possible Based on the construction of the server's name space, it is possible
that multiple pseudo filesystems may exist. For example, that multiple pseudo filesystems may exist. For example,
/a pseudo filesystem /a pseudo filesystem
/a/b real filesystem /a/b real filesystem
/a/b/c pseudo filesystem /a/b/c pseudo filesystem
/a/b/c/d real filesystem /a/b/c/d real filesystem
Each of the pseudo filesystems are considered separate entities and Each of the pseudo filesystems are considered separate entities and
therefore will have a unique fsid. therefore will have a unique fsid.
8.4. Multiple Roots 8.4. Multiple Roots
The DOS and Windows operating environments are sometimes described as The DOS and Windows operating environments are sometimes described as
having "multiple roots". Filesystems are commonly represented as having "multiple roots". Filesystems are commonly represented as
disk letters. MacOS represents filesystems as top level names. disk letters. MacOS represents filesystems as top level names.
NFSv4 servers for these platforms can construct a pseudo file system NFSv4 servers for these platforms can construct a pseudo file system
skipping to change at page 104, line 49 skipping to change at page 102, line 49
question. If the filehandles are volatile, the NFS client must be question. If the filehandles are volatile, the NFS client must be
prepared to recover a filehandle value (e.g., with a multi-component prepared to recover a filehandle value (e.g., with a multi-component
LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED. LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED.
8.6. Exported Root 8.6. Exported Root
If the server's root filesystem is exported, one might conclude that If the server's root filesystem is exported, one might conclude that
a pseudo-filesystem is not needed. This would be wrong. Assume the a pseudo-filesystem is not needed. This would be wrong. Assume the
following filesystems on a server: following filesystems on a server:
/ disk1 (exported) / disk1 (exported)
/a disk2 (not exported) /a disk2 (not exported)
/a/b disk3 (exported) /a/b disk3 (exported)
Because disk2 is not exported, disk3 cannot be reached with simple Because disk2 is not exported, disk3 cannot be reached with simple
LOOKUPs. The server must bridge the gap with a pseudo-filesystem. LOOKUPs. The server must bridge the gap with a pseudo-filesystem.
8.7. Mount Point Crossing 8.7. Mount Point Crossing
The server filesystem environment may be constructed in such a way The server filesystem environment may be constructed in such a way
that one filesystem contains a directory which is 'covered' or that one filesystem contains a directory which is 'covered' or
mounted upon by a second filesystem. For example: mounted upon by a second filesystem. For example:
/a/b (filesystem 1) /a/b (filesystem 1)
/a/b/c/d (filesystem 2) /a/b/c/d (filesystem 2)
The pseudo filesystem for this server may be constructed to look The pseudo filesystem for this server may be constructed to look
like: like:
/ (place holder/not exported) / (place holder/not exported)
/a/b (filesystem 1) /a/b (filesystem 1)
/a/b/c/d (filesystem 2) /a/b/c/d (filesystem 2)
It is the server's responsibility to present the pseudo filesystem It is the server's responsibility to present the pseudo filesystem
that is complete to the client. If the client sends a lookup request that is complete to the client. If the client sends a lookup request
for the path "/a/b/c/d", the server's response is the filehandle of for the path "/a/b/c/d", the server's response is the filehandle of
the filesystem "/a/b/c/d". In previous versions of the NFS protocol, the filesystem "/a/b/c/d". In previous versions of the NFS protocol,
the server would respond with the filehandle of directory "/a/b/c/d" the server would respond with the filehandle of directory "/a/b/c/d"
within the filesystem "/a/b". within the filesystem "/a/b".
The NFS client will be able to determine if it crosses a server mount The NFS client will be able to determine if it crosses a server mount
point by a change in the value of the "fsid" attribute. point by a change in the value of the "fsid" attribute.
skipping to change at page 106, line 5 skipping to change at page 104, line 5
the server is unable to properly determine if a client will be able the server is unable to properly determine if a client will be able
to authenticate itself. If, based on its policies, the server to authenticate itself. If, based on its policies, the server
chooses to limit the contents of the pseudo filesystem, the server chooses to limit the contents of the pseudo filesystem, the server
may effectively hide filesystems from a client that may otherwise may effectively hide filesystems from a client that may otherwise
have legitimate access. have legitimate access.
As suggested practice, the server should apply the security policy of As suggested practice, the server should apply the security policy of
a shared resource in the server's namespace to the components of the a shared resource in the server's namespace to the components of the
resource's ancestors. For example: resource's ancestors. For example:
/ /
/a/b /a/b
/a/b/c /a/b/c
The /a/b/c directory is a real filesystem and is the shared resource. The /a/b/c directory is a real filesystem and is the shared resource.
The security policy for /a/b/c is Kerberos with integrity. The The security policy for /a/b/c is Kerberos with integrity. The
server should apply the same security policy to /, /a, and /a/b. server should apply the same security policy to /, /a, and /a/b.
This allows for the extension of the protection of the server's This allows for the extension of the protection of the server's
namespace to the ancestors of the real shared resource. namespace to the ancestors of the real shared resource.
For the case of the use of multiple, disjoint security mechanisms in For the case of the use of multiple, disjoint security mechanisms in
the server's resources, the security for a particular object in the the server's resources, the security for a particular object in the
server's namespace should be the union of all security mechanisms of server's namespace should be the union of all security mechanisms of
all direct descendants. all direct descendants.
9. File Locking and Share Reservations 9. File Locking and Share Reservations
Integrating locking into the NFS protocol necessarily causes it to be Integrating locking into the NFS protocol necessarily causes it to be
stateful. With the inclusion of share reservations the protocol stateful. With the inclusion of share reservations the protocol
becomes substantially more dependent on state than the traditional becomes substantially more dependent on state than the traditional
combination of NFS and NLM (Network Lock Manager) [32]. There are combination of NFS and NLM (Network Lock Manager) [30]. There are
three components to making this state manageable: three components to making this state manageable:
o clear division between client and server o clear division between client and server
o ability to reliably detect inconsistency in state between client o ability to reliably detect inconsistency in state between client
and server and server
o simple and robust recovery mechanisms o simple and robust recovery mechanisms
In this model, the server owns the state information. The client In this model, the server owns the state information. The client
skipping to change at page 108, line 9 skipping to change at page 106, line 9
CLAIM_DELEGATE_PREV claim type, all delegation state associated with CLAIM_DELEGATE_PREV claim type, all delegation state associated with
same client with the same identity. For discussion of delegation same client with the same identity. For discussion of delegation
state recovery, see Section 10.2.1. state recovery, see Section 10.2.1.
Owners of opens and owners of byte-range locks are separate entities Owners of opens and owners of byte-range locks are separate entities
and remain separate even if the same opaque arrays are used to and remain separate even if the same opaque arrays are used to
designate owners of each. The protocol distinguishes between open- designate owners of each. The protocol distinguishes between open-
owners (represented by open_owner4 structures) and lock-owners owners (represented by open_owner4 structures) and lock-owners
(represented by lock_owner4 structures). (represented by lock_owner4 structures).
Both sorts of owners consist of a clientid and an opaque owner
string. For each client, the set of distinct owner values used with
that client constitutes the set of owners of that type, for the given
client.
Each open is associated with a specific open-owner while each byte- Each open is associated with a specific open-owner while each byte-
range lock is associated with a lock-owner and an open-owner, the range lock is associated with a lock-owner and an open-owner, the
latter being the open-owner associated with the open file under which latter being the open-owner associated with the open file under which
the LOCK operation was done. the LOCK operation was done.
Client identification is encapsulated in the following structure: Client identification is encapsulated in the following structure:
struct nfs_client_id4 { struct nfs_client_id4 {
verifier4 verifier; verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>; opaque id<NFS4_OPAQUE_LIMIT>;
skipping to change at page 121, line 41 skipping to change at page 120, line 4
for the first request issued for any given state-owner. for the first request issued for any given state-owner.
Note that for requests that contain a sequence number, for each Note that for requests that contain a sequence number, for each
state-owner, there should be no more than one outstanding request. state-owner, there should be no more than one outstanding request.
If a request (r) with a previous sequence number (r < L) is received, If a request (r) with a previous sequence number (r < L) is received,
it is rejected with the return of error NFS4ERR_BAD_SEQID. Given a it is rejected with the return of error NFS4ERR_BAD_SEQID. Given a
properly-functioning client, the response to (r) must have been properly-functioning client, the response to (r) must have been
received before the last request (L) was sent. If a duplicate of received before the last request (L) was sent. If a duplicate of
last request (r == L) is received, the stored response is returned. last request (r == L) is received, the stored response is returned.
If a request beyond the next sequence (r == L + 2) is received, it is If a request beyond the next sequence (r == L + 2) is received, it is
rejected with the return of error NFS4ERR_BAD_SEQID. Sequence rejected with the return of error NFS4ERR_BAD_SEQID. Sequence
history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM history is reinitialized whenever the SETCLIENTID/SETCLIENTID_CONFIRM
sequence changes the client verifier. sequence changes the client verifier.
Since the sequence number is represented with an unsigned 32-bit Since the sequence number is represented with an unsigned 32-bit
integer, the arithmetic involved with the sequence number is mod integer, the arithmetic involved with the sequence number is mod
2^32. For an example of modulo arithmetic involving sequence numbers 2^32. For an example of modulo arithmetic involving sequence numbers
see [33]. see [31].
It is critical the server maintain the last response sent to the It is critical the server maintain the last response sent to the
client to provide a more reliable cache of duplicate non-idempotent client to provide a more reliable cache of duplicate non-idempotent
requests than that of the traditional cache described in [34]. The requests than that of the traditional cache described in [32]. The
traditional duplicate request cache uses a least recently used traditional duplicate request cache uses a least recently used
algorithm for removing unneeded requests. However, the last lock algorithm for removing unneeded requests. However, the last lock
request and response on a given state-owner must be cached as long as request and response on a given state-owner must be cached as long as
the lock state exists on the server. the lock state exists on the server.
The client MUST monotonically increment the sequence number for the The client MUST monotonically increment the sequence number for the
CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
operations. This is true even in the event that the previous operations. This is true even in the event that the previous
operation that used the sequence number received an error. The only operation that used the sequence number received an error. The only
exception to this rule is if the previous operation received one of exception to this rule is if the previous operation received one of
skipping to change at page 122, line 33 skipping to change at page 120, line 46
the methods described above, there are no risks of a Byzantine router the methods described above, there are no risks of a Byzantine router
re-sending old requests. The server need only maintain the (state- re-sending old requests. The server need only maintain the (state-
owner, sequence number) state as long as there are open files or owner, sequence number) state as long as there are open files or
closed files with locks outstanding. closed files with locks outstanding.
LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a sequence LOCK, LOCKU, OPEN, OPEN_DOWNGRADE, and CLOSE each contain a sequence
number and therefore the risk of the replay of these operations number and therefore the risk of the replay of these operations
resulting in undesired effects is non-existent while the server resulting in undesired effects is non-existent while the server
maintains the state-owner state. maintains the state-owner state.
9.1.8. Releasing state-owner State 9.1.8. Interactions of multiple sequence values
Some Operations may have multiple sources of data for request
sequence checking and retrannsmision determination. Some Operations
have multiple sequence values associated with multiple types of
state-owners. In addition, such Operations may also have a stateid
with its own seqid value, that will be checked for validity.
As noted above, there may be multiple sequence values to check The
following rules should be followed by the server in processing these
multiple sequence values within a single operation.
o When a sequence value associated with a state-owner is unavailable
for checking because the state-owner is unknown to the server, it
take no part in the comparison. Similarly, when the stateid seqid
is given as zero, the stateid seqid takes no part in the checking.
o When any of the state-owner sequence values are invalid,
NFS4ERR_BADSEQ is returned. When a stateid sequence is checked,
NFSS4ERR_BAD_STATEID, or NFS4ERR_OLDSTATEID is returned as
appropriate, but NFS4ERR_BADSEQ has priority.
o When any one of the sequence values matches a previous request,
for a state-owner, it is treated a retransmission and not re-
executed. When the type of the operation doe not match that
originally used, NFS4ERR_BADSEQ is returned. When the server can
determine that the request differs from the original it may return
NFS4ERR_BADSEQ.
o When multiple of the sequence values match previous operations,
but the operations are not the same, NFS4ERR_BADSEQ is returned.
o When there are no available sequence values available for
comparison and the operation is an OPEN, the server indicates to
the client that an OPEN_CONFRIM is required, unless it can
conclusively determine that confirmation is not required (e.g., by
knowing that no open-owner state has ever been released for the
current clientid).
For other operations, lack of available sequence values for
checking can only result from specification of a stateid with a
sequence value of zero.
Because specification of stateids with a sequence value of zero can
result in no sequence checking under certain conditions, clients
should avoid using them in connection with operations in which state-
owners are used together with state-owner sequence values.
9.1.9. Releasing state-owner State
When a particular state-owner no longer holds open or file locking When a particular state-owner no longer holds open or file locking
state at the server, the server may choose to release the sequence state at the server, the server may choose to release the sequence
number state associated with the state-owner. The server may make number state associated with the state-owner. The server may make
this choice based on lease expiration, for the reclamation of server this choice based on lease expiration, for the reclamation of server
memory, or other implementation specific details. In any event, the memory, or other implementation specific details. Note that when
server is able to do this safely only when the state-owner no longer this is done, a retransmitted request, normally identified by a
is being utilized by the client. The server may choose to hold the matching state-owner sequence may not be correctly recognized, so
state-owner state in the event that retransmitted requests are that the client will not receive the original response that it would
received. However, the period to hold this state is implementation have if the state-owner state was not released.
specific.
If the server were able to be sure that a given state-owner would
never again be used by a client, such an issue could not arise. Even
when the state-owner state is released and the client subsequently
uses that state-owner, retransmitted requests will be detected as
invalid and the request not executed, although the client may have a
recovery path that is more complicated than simply getting the
original response back transparently.
In any event, the server is able to safely release state-owner state
(in the sense that retransmitted requests will not be erroneously
acted upon) when the state-owner no currently being utilized by the
client (i.e., there are no open files associated with an open-owner
and no lock stateids associated with a lock-owner). The server may
choose to hold the state-owner state in order to simplify the
recovery path, in the case in which retransmissions of currently
active requests are received. However, the period it chooses to hold
this state is implementation specific.
In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is In the case that a LOCK, LOCKU, OPEN_DOWNGRADE, or CLOSE is
retransmitted after the server has previously released the state- retransmitted after the server has previously released the state-
owner state, the server will find that the state-owner has no files owner state, the server will find that the state-owner has no files
open and an error will be returned to the client. If the state-owner open and an error will be returned to the client. If the state-owner
does have a file open, the stateid will not match and again an error does have a file open, the stateid will not match and again an error
is returned to the client. is returned to the client.
9.1.9. Use of Open Confirmation 9.1.10. Use of Open Confirmation
In the case that an OPEN is retransmitted and the open-owner is being In the case that an OPEN is retransmitted and the open-owner is being
used for the first time or the open-owner state has been previously used for the first time or the open-owner state has been previously
released by the server, the use of the OPEN_CONFIRM operation will released by the server, the use of the OPEN_CONFIRM operation will
prevent incorrect behavior. When the server observes the use of the prevent incorrect behavior. When the server observes the use of the
open-owner for the first time, it will direct the client to perform open-owner for the first time, it will direct the client to perform
the OPEN_CONFIRM for the corresponding OPEN. This sequence the OPEN_CONFIRM for the corresponding OPEN. This sequence
establishes the use of a open-owner and associated sequence number. establishes the use of a open-owner and associated sequence number.
Since the OPEN_CONFIRM sequence connects a new open-owner on the Since the OPEN_CONFIRM sequence connects a new open-owner on the
server with an existing open-owner on a client, the sequence number server with an existing open-owner on a client, the sequence number
skipping to change at page 129, line 7 skipping to change at page 128, line 36
requests to be processed during the grace period, it MUST determine requests to be processed during the grace period, it MUST determine
that no lock subsequently reclaimed will be rejected and that no lock that no lock subsequently reclaimed will be rejected and that no lock
subsequently reclaimed would have prevented any I/O operation subsequently reclaimed would have prevented any I/O operation
processed during the grace period. processed during the grace period.
Clients should be prepared for the return of NFS4ERR_GRACE errors for Clients should be prepared for the return of NFS4ERR_GRACE errors for
non-reclaim lock and I/O requests. In this case the client should non-reclaim lock and I/O requests. In this case the client should
employ a retry mechanism for the request. A delay (on the order of employ a retry mechanism for the request. A delay (on the order of
several seconds) between retries should be used to avoid overwhelming several seconds) between retries should be used to avoid overwhelming
the server. Further discussion of the general issue is included in the server. Further discussion of the general issue is included in
[20]. The client must account for the server that is able to perform [19]. The client must account for the server that is able to perform
I/O and non-reclaim locking requests within the grace period as well I/O and non-reclaim locking requests within the grace period as well
as those that cannot do so. as those that cannot do so.
A reclaim-type locking request outside the server's grace period can A reclaim-type locking request outside the server's grace period can
only succeed if the server can guarantee that no conflicting lock or only succeed if the server can guarantee that no conflicting lock or
I/O request has been granted since reboot or restart. I/O request has been granted since reboot or restart.
A server may, upon restart, establish a new value for the lease A server may, upon restart, establish a new value for the lease
period. Therefore, clients should, once a new client ID is period. Therefore, clients should, once a new client ID is
established, refetch the lease_time attribute and use it as the basis established, refetch the lease_time attribute and use it as the basis
skipping to change at page 130, line 25 skipping to change at page 130, line 6
o Server's responsibility: A server MUST NOT allow a client to o Server's responsibility: A server MUST NOT allow a client to
reclaim a lock unless it knows that it could not have since reclaim a lock unless it knows that it could not have since
granted a conflicting lock. However, in deciding whether a granted a conflicting lock. However, in deciding whether a
conflicting lock could have been granted, it is permitted to conflicting lock could have been granted, it is permitted to
assume its clients are responsible, as above. assume its clients are responsible, as above.
A server may consider a client's lease "successfully established" A server may consider a client's lease "successfully established"
once it has received an open operation from that client. once it has received an open operation from that client.
The next sections give examples showing what can go wrong if these The next sections give examples showing what can go wrong if these
responsibilites are neglected, and provides examples of server responsibilities are neglected, and provides examples of server
implementation strategies that could meet a server's implementation strategies that could meet a server's
responsibilities. responsibilities.
9.6.3.1.1. First Server Edge Condition 9.6.3.1.1. First Server Edge Condition
The first edge condition has the following scenario: The first edge condition has the following scenario:
1. Client A acquires a lock. 1. Client A acquires a lock.
2. Client A and server experience mutual network partition, such 2. Client A and server experience mutual network partition, such
skipping to change at page 137, line 42 skipping to change at page 137, line 22
is a separate and independent mechanism from byte-range locking. is a separate and independent mechanism from byte-range locking.
When a client opens a file, it issues an OPEN operation to the server When a client opens a file, it issues an OPEN operation to the server
specifying the type of access required (READ, WRITE, or BOTH) and the specifying the type of access required (READ, WRITE, or BOTH) and the
type of access to deny others (OPEN4_SHARE_DENY_NONE, type of access to deny others (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 OPEN fails the client will fail the OPEN4_SHARE_DENY_BOTH). If the OPEN fails the client will fail the
application's open request. application's open request.
Pseudo-code definition of the semantics: Pseudo-code definition of the semantics:
if (request.access == 0) if (request.access == 0)
return (NFS4ERR_INVAL) return (NFS4ERR_INVAL)
else if ((request.access & file_state.deny)) || else if ((request.access & file_state.deny)) ||
(request.deny & file_state.access)) (request.deny & file_state.access))
return (NFS4ERR_DENIED) return (NFS4ERR_DENIED)
This checking of share reservations on OPEN is done with no exception This checking of share reservations on OPEN is done with no exception
for an existing OPEN for the same open-owner. for an existing OPEN for the same open-owner.
The constants used for the OPEN and OPEN_DOWNGRADE operations for the The constants used for the OPEN and OPEN_DOWNGRADE operations for the
access and deny fields are as follows: access and deny fields are as follows:
const OPEN4_SHARE_ACCESS_READ = 0x00000001; const OPEN4_SHARE_ACCESS_READ = 0x00000001;
const OPEN4_SHARE_ACCESS_WRITE = 0x00000002; const OPEN4_SHARE_ACCESS_WRITE = 0x00000002;
const OPEN4_SHARE_ACCESS_BOTH = 0x00000003; const OPEN4_SHARE_ACCESS_BOTH = 0x00000003;
skipping to change at page 166, line 26 skipping to change at page 165, line 50
sufficient disk space is available within the target filesystem. sufficient disk space is available within the target filesystem.
Such saving may also be restricted to situations when the client has Such saving may also be restricted to situations when the client has
sufficient buffering resources to keep the cached copy available sufficient buffering resources to keep the cached copy available
until it is properly stored to the target filesystem. until it is properly stored to the target filesystem.
10.6. Attribute Caching 10.6. Attribute Caching
The attributes discussed in this section do not include named The attributes discussed in this section do not include named
attributes. Individual named attributes are analogous to files and attributes. Individual named attributes are analogous to files and
caching of the data for these needs to be handled just as data caching of the data for these needs to be handled just as data
caching is for ordinary files. Similarly, LOOKUP results from an caching is for regular files. Similarly, LOOKUP results from an
OPENATTR directory are to be cached on the same basis as any other OPENATTR directory are to be cached on the same basis as any other
pathnames and similarly for directory contents. pathnames and similarly for directory contents.
Clients may cache file attributes obtained from the server and use Clients may cache file attributes obtained from the server and use
them to avoid subsequent GETATTR requests. Such caching is write them to avoid subsequent GETATTR requests. Such caching is write
through in that modification to file attributes is always done by through in that modification to file attributes is always done by
means of requests to the server and should not be done locally and means of requests to the server and should not be done locally and
cached. The exception to this are modifications to attributes that cached. The exception to this are modifications to attributes that
are intimately connected with data caching. Therefore, extending a are intimately connected with data caching. Therefore, extending a
file by writing data to the local data cache is reflected immediately file by writing data to the local data cache is reflected immediately
skipping to change at page 178, line 29 skipping to change at page 177, line 47
equivalence classes defined by the chosen equivalence relation. equivalence classes defined by the chosen equivalence relation.
In the NFSv4 protocol, handling of issues related to In the NFSv4 protocol, handling of issues related to
internationalization with regard to normalization follows one of two internationalization with regard to normalization follows one of two
basic patterns: basic patterns:
o For strings whose function is related to other internet standards, o For strings whose function is related to other internet standards,
such as server and domain naming, the normalization form defined such as server and domain naming, the normalization form defined
by the appropriate internet standards is used. For server and by the appropriate internet standards is used. For server and
domain naming, this involves normalization form NFKC as specified domain naming, this involves normalization form NFKC as specified
in [10] in [3]
o For other strings, particular those passed by the server to file o For other strings, particular those passed by the server to file
system implementations, normalization requirements are the system implementations, normalization requirements are the
province of the file system and the job of this specification is province of the file system and the job of this specification is
not to specify a particular form but to make sure that not to specify a particular form but to make sure that
interoperability is maximized, even when clients and server-based interoperability is maximized, even when clients and server-based
file systems have different preferences. file systems have different preferences.
A related but distinct issue concerns string confusability. This can A related but distinct issue concerns string confusability. This can
occur when two strings (including single-character strings) having a occur when two strings (including single-character strings) having a
skipping to change at page 179, line 29 skipping to change at page 178, line 44
(U+0070) (also with MATHEMATICAL BOLD SMALL P (U+1D429) and GREEK (U+0070) (also with MATHEMATICAL BOLD SMALL P (U+1D429) and GREEK
SMALL LETTER RHO (U+1D56, for good measure). SMALL LETTER RHO (U+1D56, for good measure).
NFSv4, as it does with normalization, takes a two-part approach to NFSv4, as it does with normalization, takes a two-part approach to
this issue: this issue:
o For strings whose function is related to other internet standards, o For strings whose function is related to other internet standards,
such as server and domain naming, any string processing to address such as server and domain naming, any string processing to address
the confusability issue is defined by the appropriate internet the confusability issue is defined by the appropriate internet
standards is used. For server and domain naming, this is the standards is used. For server and domain naming, this is the
responsibility of IDNA as described in [10]. responsibility of IDNA as described in [3].
o For other strings, particularly those passed by the server to file o For other strings, particularly those passed by the server to file
system implementations, any such preparation requirements system implementations, any such preparation requirements
including the choice of how, or whether to address the including the choice of how, or whether to address the
confusability issue, are the responsibility of the file system to confusability issue, are the responsibility of the file system to
define, and for this specification to try to add its own set would define, and for this specification to try to add its own set would
add unacceptably to complexity, and make many files accessible add unacceptably to complexity, and make many files accessible
locally and by other remote file access protocols, inaccessible by locally and by other remote file access protocols, inaccessible by
NFSv4. This specification defines how the protocol maximizes NFSv4. This specification defines how the protocol maximizes
interoperability in the face of different file system interoperability in the face of different file system
skipping to change at page 181, line 13 skipping to change at page 180, line 24
specific Processing". specific Processing".
12.2.2. Divisions by Typedef Parent types 12.2.2. Divisions by Typedef Parent types
There are a number of different string types within NFSv4 and There are a number of different string types within NFSv4 and
internationalization handling will be different for different types internationalization handling will be different for different types
of strings. Each the types will be in one of four groups based on of strings. Each the types will be in one of four groups based on
the parent type that specifies the nature of its relationship to utf8 the parent type that specifies the nature of its relationship to utf8
and ascii. and ascii.
utf8_should/USHOULD: indicating that strings of this type SHOULD be utf8_expected/USHOULD: indicating that strings of this type SHOULD
UTF-8 but clients and servers will not check for valid UTF-8 be UTF-8 but clients and servers will not check for valid UTF-8
encoding. encoding.
utf8val_should/UVSHOULD: indicating that strings of this type SHOULD utf8val_RECOMMENDED4/UVSHOULD: indicating that strings of this type
be and generally will be in the form of the UTF-8 encoding of SHOULD be and generally will be in the form of the UTF-8 encoding
Unicode. Strings in most cases will be checked by the server for of Unicode. Strings in most cases will be checked by the server
valid UTF-8 but for certain file systems, such checking may be for valid UTF-8 but for certain file systems, such checking may be
inhibited. inhibited.
utf8val_must/UVMUST: indicating that strings of this type MUST be in utf8val_REQUIRED4/UVMUST: indicating that strings of this type MUST
the form of the UTF-8 encoding of Unicode. Strings will be be in the form of the UTF-8 encoding of Unicode. Strings will be
checked by the server for valid UTF-8 and the server SHOULD ensure checked by the server for valid UTF-8 and the server SHOULD ensure
that when sent to the client, they are valid UTF-8. that when sent to the client, they are valid UTF-8.
ascii_must/ASCII: indicating that strings of this type MUST be pure ascii_REQUIRED4/ASCII: indicating that strings of this type MUST be
ASCII, and thus automatically UTF-8. The processing of these sent and validated as ASCII, and thus are automatically UTF-8.
string must ensure that they are only have ASCII characters but The processing of these string must ensure that they are only have
this need not be a separate step if any normally required check ASCII characters but this need not be a separate step if any
for validity inherently assures that only ASCII characters are normally required check for validity inherently assures that only
present. ASCII characters are present.
In those cases where UTF-8 is not required, USHOULD and UVSHOULD, and In those cases where UTF-8 is not required, USHOULD and UVSHOULD, and
strings that are not valid UTF-8 are received and accepted, the strings that are not valid UTF-8 are received and accepted, the
receiver MUST NOT modify the strings. For example, setting receiver MUST NOT modify the strings. For example, setting
particular bits such as the high-order bit to zero MUST NOT be done. particular bits such as the high-order bit to zero MUST NOT be done.
12.2.3. Individual Types and Their Handling 12.2.3. Individual Types and Their Handling
The first table outlines the handling for the primary string types, The first table outlines the handling for the primary string types,
i.e., those not derived as a prefix or a suffix from a mixture type. i.e., those not derived as a prefix or a suffix from a mixture type.
+-----------------+----------+-------+------------------------------+ +-----------------+----------+-------+------------------------------+
| Type | Parent | Class | Explanation | | Type | Parent | Class | Explanation |
+-----------------+----------+-------+------------------------------+ +-----------------+----------+-------+------------------------------+
| comptag4 | USHOULD | NIP | Should be utf8 but no | | comptag4 | USHOULD | NIP | Tag expected to be UTF-8but |
| | | | validation by server or | | | | | no validation by server or |
| | | | client is to be done. | | | | | client is to be done. |
| component4 | UVSHOULD | NFS | Should be utf8 but clients | | component4 | UVSHOULD | NFS | Should be utf8 but clients |
| | | | may need to access file | | | | | may need to access file |
| | | | systems with a different | | | | | systems with a different |
| | | | name structure, such as file | | | | | name structure, such as file |
| | | | systems that have non-utf8 | | | | | systems that have non-utf8 |
| | | | names. | | | | | names. |
| linktext4 | UVSHOULD | NFS | Should be utf8 since text | | linktext4 | UVSHOULD | NFS | Should be utf8 since text |
| | | | may include name components. | | | | | may include name components. |
| | | | Because of the need to | | | | | Because of the need to |
skipping to change at page 183, line 27 skipping to change at page 182, line 31
| | | | domain. | | | | | domain. |
+----------+--------+------+----------------------------------------+ +----------+--------+------+----------------------------------------+
Table 7 Table 7
12.3. Errors Related to Strings 12.3. Errors Related to Strings
When the client sends an invalid UTF-8 string in a context in which When the client sends an invalid UTF-8 string in a context in which
UTF-8 is REQUIRED, the server MUST return an NFS4ERR_INVAL error. UTF-8 is REQUIRED, the server MUST return an NFS4ERR_INVAL error.
Within the framework of the previous section, this applies to strings Within the framework of the previous section, this applies to strings
whose type is defined as utf8val_must or ascii_must. When the client whose type is defined as utf8val_REQUIRED4 or ascii_REQUIRED4. When
sends an invalid UTF-8 string in a context in which UTF-8 is the client sends an invalid UTF-8 string in a context in which UTF-8
RECOMMENDED and the server should test for UTF-8, the server SHOULD is RECOMMENDED and the server should test for UTF-8, the server
return an NFS4ERR_INVAL error. Within the framework of the previous SHOULD return an NFS4ERR_INVAL error. Within the framework of the
section, this applies to strings whose type is defined as previous section, this applies to strings whose type is defined as
utf8val_should. These situations apply to cases in which utf8val_RECOMMENDED4. These situations apply to cases in which
inappropriate prefixes are detected and where the count includes inappropriate prefixes are detected and where the count includes
trailing bytes that do not constitute a full UCS character. trailing bytes that do not constitute a full UCS character.
Where the client-supplied string is valid UTF-8 but contains Where the client-supplied string is valid UTF-8 but contains
characters that are not supported by the server file system as a characters that are not supported by the server file system as a
value for that string (e.g., names containing characters that have value for that string (e.g., names containing characters that have
more than two octets on a file system that supports UCS-2 characters more than two octets on a file system that supports UCS-2 characters
only, file name components containing slashes on file systems that do only, file name components containing slashes on file systems that do
not allow them in file name components), the server MUST return an not allow them in file name components), the server MUST return an
NFS4ERR_BADCHAR error. NFS4ERR_BADCHAR error.
skipping to change at page 186, line 28 skipping to change at page 185, line 33
When a domain string is part of id@domain or group@domain, the server When a domain string is part of id@domain or group@domain, the server
SHOULD map domain strings which are A-labels or are UTF-8 domain SHOULD map domain strings which are A-labels or are UTF-8 domain
names which are not U-labels, to the corresponding U-label, using names which are not U-labels, to the corresponding U-label, using
ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a result, the ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a result, the
domain name returned within a userid on a GETATTR may not match that domain name returned within a userid on a GETATTR may not match that
sent when the userid is set using SETATTR, although when this sent when the userid is set using SETATTR, although when this
happens, the domain will be in the form of a U-label. When the happens, the domain will be in the form of a U-label. When the
server does not map domain strings which are not U-labels into a server does not map domain strings which are not U-labels into a
U-label, which it MAY do, it MUST NOT modify the domain and the U-label, which it MAY do, it MUST NOT modify the domain and the
domain returned on a GETATTR of the userid MUST be the same as that domain returned on a GETATTR of the userid MUST be the same as that
used when setting the userid by the SETATTTR. used when setting the userid by the SETATTR.
The server MAY implement VERIFY and NVERIFY without translating The server MAY implement VERIFY and NVERIFY without translating
internal state to a string form, so that, for example, a user internal state to a string form, so that, for example, a user
principal which represents a specific numeric user id, will match a principal which represents a specific numeric user id, will match a
different principal string which represents the same numeric user id. different principal string which represents the same numeric user id.
12.7. String Types with NFS-specific Processing 12.7. String Types with NFS-specific Processing
For a number of data types within NFSv4, the primary responsibility For a number of data types within NFSv4, the primary responsibility
for internationalization-related handling is that of some entity for internationalization-related handling is that of some entity
skipping to change at page 196, line 26 skipping to change at page 195, line 30
returning NFS4ERR_BADNAME. returning NFS4ERR_BADNAME.
Clients may encounter names with bidirectional strings returned in Clients may encounter names with bidirectional strings returned in
responses from the server. If clients treat such strings as not responses from the server. If clients treat such strings as not
valid file name components, it is up to the client whether it simply valid file name components, it is up to the client whether it simply
ignores these files or modifies the name component to meet its own ignores these files or modifies the name component to meet its own
rules for acceptable name component strings. rules for acceptable name component strings.
12.7.2. Processing of Link Text 12.7.2. Processing of Link Text
Symbolic link text is defined as utf8val_should and therefore the Symbolic link text is defined as utf8val_RECOMMENDED4 and therefore
server SHOULD validate link text on a CREATE and return NFS4ERR_INVAL the server SHOULD validate link text on a CREATE and return
if it is is not valid UTF-8. Note that file systems which treat NFS4ERR_INVAL if it is is not valid UTF-8. Note that file systems
names as strings of byte are an exception for which such validation which treat names as strings of byte are an exception for which such
need not be done. One other situation in which an NFSv4 might choose validation need not be done. One other situation in which an NFSv4
(or be configured) not to make such a check is when links within file might choose (or be configured) not to make such a check is when
system reference names in another which is configured to treat names links within file system reference names in another which is
as strings of bytes. configured to treat names as strings of bytes.
On the other hand, UTF-8 validation of symbolic link text need not be On the other hand, UTF-8 validation of symbolic link text need not be
done on the data resulting from a READLINK. Such data might have done on the data resulting from a READLINK. Such data might have
been stored by an NFS Version 4 server configured to allow non-UTF-8 been stored by an NFS Version 4 server configured to allow non-UTF-8
link text or it might have resulted from symbolic link text stored link text or it might have resulted from symbolic link text stored
via local file system access or access via another remote file access via local file system access or access via another remote file access
protocol. protocol.
Note that because of the role of the symbolic link, as data stored Note that because of the role of the symbolic link, as data stored
and read by the user, other sorts of validations or modifications and read by the user, other sorts of validations or modifications
skipping to change at page 205, line 17 skipping to change at page 204, line 23
accounting purposes), and where cross-connection between the accounting purposes), and where cross-connection between the
regions are not allowed. regions are not allowed.
13.1.5. State Management Errors 13.1.5. State Management Errors
These errors indicate problems with the stateid (or one of the These errors indicate problems with the stateid (or one of the
stateids) passed to a given operation. This includes situations in stateids) passed to a given operation. This includes situations in
which the stateid is invalid as well as situations in which the which the stateid is invalid as well as situations in which the
stateid is valid but designates revoked locking state. Depending on stateid is valid but designates revoked locking state. Depending on
the operation, the stateid when valid may designate opens, byte-range the operation, the stateid when valid may designate opens, byte-range
locks, file or directory delegations, layouts, or device maps. locks, file delegations, layouts, or device maps.
13.1.5.1. NFS4ERR_ADMIN_REVOKED (Error Code 10047) 13.1.5.1. NFS4ERR_ADMIN_REVOKED (Error Code 10047)
A stateid designates locking state of any type that has been revoked A stateid designates locking state of any type that has been revoked
due to administrative interaction, possibly while the lease is valid. due to administrative interaction, possibly while the lease is valid.
13.1.5.2. NFS4ERR_BAD_STATEID (Error Code 10026) 13.1.5.2. NFS4ERR_BAD_STATEID (Error Code 10026)
A stateid generated by the current server instance, but which does A stateid generated by the current server instance, but which does
not designate any locking state (either current or superseded) for a not designate any locking state (either current or superseded) for a
skipping to change at page 208, line 23 skipping to change at page 207, line 25
A locking request was attempted which would require the upgrade or A locking request was attempted which would require the upgrade or
downgrade of a lock range already held by the owner when the server downgrade of a lock range already held by the owner when the server
does not support atomic upgrade or downgrade of locks. does not support atomic upgrade or downgrade of locks.
13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028) 13.1.8.8. NFS4ERR_LOCK_RANGE (Error Code 10028)
A lock request is operating on a range that overlaps in part a A lock request is operating on a range that overlaps in part a
currently held lock for the current lock owner and does not precisely currently held lock for the current lock owner and does not precisely
match a single such lock where the server does not support this type match a single such lock where the server does not support this type
of request, and thus does not implement POSIX locking semantics [35]. of request, and thus does not implement POSIX locking semantics [33].
See Section 15.12.5, Section 15.13.5, and Section 15.14.5 for a See Section 15.12.5, Section 15.13.5, and Section 15.14.5 for a
discussion of how this applies to LOCK, LOCKT, and LOCKU discussion of how this applies to LOCK, LOCKT, and LOCKU
respectively. respectively.
13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038) 13.1.8.9. NFS4ERR_OPENMODE (Error Code 10038)
The client attempted a READ, WRITE, LOCK or other operation not The client attempted a READ, WRITE, LOCK or other operation not
sanctioned by the stateid passed (e.g., writing to a file opened only sanctioned by the stateid passed (e.g., writing to a file opened only
for read). for read).
skipping to change at page 223, line 5 skipping to change at page 222, line 5
COMPOUND as described above. COMPOUND as described above.
The basic structure of the COMPOUND procedure is: The basic structure of the COMPOUND procedure is:
+-----+--------------+--------+-----------+-----------+-----------+-- +-----+--------------+--------+-----------+-----------+-----------+--
| tag | minorversion | numops | op + args | op + args | op + args | | tag | minorversion | numops | op + args | op + args | op + args |
+-----+--------------+--------+-----------+-----------+-----------+-- +-----+--------------+--------+-----------+-----------+-----------+--
and the reply's structure is: and the reply's structure is:
+------------+-----+--------+-----------------------+-- +------------+-----+--------+-----------------------+--
|last status | tag | numres | status + op + results | |last status | tag | numres | status + op + results |
+------------+-----+--------+-----------------------+-- +------------+-----+--------+-----------------------+--
The numops and numres fields, used in the depiction above, represent The numops and numres fields, used in the depiction above, represent
the count for the counted array encoding use to signify the number of the count for the counted array encoding use to signify the number of
arguments or results encoded in the request and response. As per the arguments or results encoded in the request and response. As per the
XDR encoding, these counts must match exactly the number of operation XDR encoding, these counts must match exactly the number of operation
arguments or results encoded. arguments or results encoded.
14.2. Evaluation of a Compound Request 14.2. Evaluation of a Compound Request
The server will process the COMPOUND procedure by evaluating each of The server will process the COMPOUND procedure by evaluating each of
skipping to change at page 224, line 37 skipping to change at page 223, line 37
operation values. To avoid overlap with the RPC procedure numbers, operation values. To avoid overlap with the RPC procedure numbers,
operations 0 (zero) and 1 are not defined. Operation 2 is not operations 0 (zero) and 1 are not defined. Operation 2 is not
defined but reserved for future use with minor versioning. defined but reserved for future use with minor versioning.
15. NFSv4 Procedures 15. NFSv4 Procedures
15.1. Procedure 0: NULL - No Operation 15.1. Procedure 0: NULL - No Operation
15.1.1. SYNOPSIS 15.1.1. SYNOPSIS
<null> <null>
15.1.2. ARGUMENT 15.1.2. ARGUMENT
void; void;
15.1.3. RESULT 15.1.3. RESULT
void; void;
15.1.4. DESCRIPTION 15.1.4. DESCRIPTION
Standard NULL procedure. Void argument, void response. This Standard NULL procedure. Void argument, void response. This
procedure has no functionality associated with it. Because of this procedure has no functionality associated with it. Because of this
it is sometimes used to measure the overhead of processing a service it is sometimes used to measure the overhead of processing a service
request. Therefore, the server should ensure that no unnecessary request. Therefore, the server should ensure that no unnecessary
work is done in servicing this procedure. work is done in servicing this procedure.
15.2. Procedure 1: COMPOUND - Compound Operations 15.2. Procedure 1: COMPOUND - Compound Operations
15.2.1. SYNOPSIS 15.2.1. SYNOPSIS
compoundargs -> compoundres compoundargs -> compoundres
15.2.2. ARGUMENT 15.2.2. ARGUMENT
union nfs_argop4 switch (nfs_opnum4 argop) { union nfs_argop4 switch (nfs_opnum4 argop) {
case <OPCODE>: <argument>; case <OPCODE>: <argument>;
... ...
}; };
struct COMPOUND4args { struct COMPOUND4args {
comptag4 tag; comptag4 tag;
uint32_t minorversion; uint32_t minorversion;
nfs_argop4 argarray<>; nfs_argop4 argarray<>;
}; };
15.2.3. RESULT 15.2.3. RESULT
union nfs_resop4 switch (nfs_opnum4 resop) { union nfs_resop4 switch (nfs_opnum4 resop) {
case <OPCODE>: <argument>; case <OPCODE>: <argument>;
... ...
}; };
struct COMPOUND4res { struct COMPOUND4res {
nfsstat4 status; nfsstat4 status;
comptag4 tag; comptag4 tag;
nfs_resop4 resarray<>; nfs_resop4 resarray<>;
}; };
15.2.4. DESCRIPTION 15.2.4. DESCRIPTION
The COMPOUND procedure is used to combine one or more of the NFS The COMPOUND procedure is used to combine one or more of the NFS
skipping to change at page 227, line 35 skipping to change at page 226, line 35
15.2.4.1. Current Filehandle 15.2.4.1. Current Filehandle
The current and saved filehandle are used throughout the protocol. The current and saved filehandle are used throughout the protocol.
Most operations implicitly use the current filehandle as a argument Most operations implicitly use the current filehandle as a argument
and many set the current filehandle as part of the results. The and many set the current filehandle as part of the results. The
combination of client specified sequences of operations and current combination of client specified sequences of operations and current
and saved filehandle arguments and results allows for greater and saved filehandle arguments and results allows for greater
protocol flexibility. The best or easiest example of current protocol flexibility. The best or easiest example of current
filehandle usage is a sequence like the following: filehandle usage is a sequence like the following:
PUTFH fh1 {fh1} PUTFH fh1 {fh1}
LOOKUP "compA" {fh2} LOOKUP "compA" {fh2}
GETATTR {fh2} GETATTR {fh2}
LOOKUP "compB" {fh3} LOOKUP "compB" {fh3}
GETATTR {fh3} GETATTR {fh3}
LOOKUP "compC" {fh4} LOOKUP "compC" {fh4}
GETATTR {fh4} GETATTR {fh4}
GETFH GETFH
Figure 1 Figure 1
In this example, the PUTFH (Section 15.22) operation explicitly sets In this example, the PUTFH (Section 15.22) operation explicitly sets
the current filehandle value while the result of each LOOKUP the current filehandle value while the result of each LOOKUP
operation sets the current filehandle value to the resultant file operation sets the current filehandle value to the resultant file
system object. Also, the client is able to insert GETATTR operations system object. Also, the client is able to insert GETATTR operations
using the current filehandle as an argument. using the current filehandle as an argument.
The PUTROOTFH (Section 15.24) and PUTPUBFH (Section 15.24) operations The PUTROOTFH (Section 15.24) and PUTPUBFH (Section 15.24) operations
skipping to change at page 229, line 5 skipping to change at page 228, line 5
current filehandle will also change the current stateid to {0, 0}. current filehandle will also change the current stateid to {0, 0}.
The SAVEFH and RESTOREFH operations will save and restore both the The SAVEFH and RESTOREFH operations will save and restore both the
current filehandle and the current stateid as a set. current filehandle and the current stateid as a set.
The following example is the common case of a simple READ operation The following example is the common case of a simple READ operation
with a supplied stateid showing that the PUTFH initializes the with a supplied stateid showing that the PUTFH initializes the
current stateid to (0, 0). The subsequent READ with stateid (sid1) current stateid to (0, 0). The subsequent READ with stateid (sid1)
leaves the current stateid unchanged, but does evaluate the the leaves the current stateid unchanged, but does evaluate the the
operation. operation.
PUTFH fh1 - -> {fh1, (0, 0)} PUTFH fh1 - -> {fh1, (0, 0)}
READ (sid1), 0, 1024 {fh1, (0, 0)} -> {fh1, (0, 0)} READ (sid1), 0, 1024 {fh1, (0, 0)} -> {fh1, (0, 0)}
Figure 2 Figure 2
This next example performs an OPEN with the root filehandle and as a This next example performs an OPEN with the root filehandle and as a
result generates stateid (sid1). The next operation specifies the result generates stateid (sid1). The next operation specifies the
READ with the argument stateid set such that (seqid, other) are equal READ with the argument stateid set such that (seqid, other) are equal
to (1, 0), but the current stateid set by the previous operation is to (1, 0), but the current stateid set by the previous operation is
actually used when the operation is evaluated. This allows correct actually used when the operation is evaluated. This allows correct
interaction with any existing, potentially conflicting, locks. interaction with any existing, potentially conflicting, locks.
PUTROOTFH - -> {fh1, (0, 0)} PUTROOTFH - -> {fh1, (0, 0)}
OPEN "compA" {fh1, (0, 0)} -> {fh2, (sid1)} OPEN "compA" {fh1, (0, 0)} -> {fh2, (sid1)}
READ (1, 0), 0, 1024 {fh2, (sid1)} -> {fh2, (sid1)} READ (1, 0), 0, 1024 {fh2, (sid1)} -> {fh2, (sid1)}
CLOSE (1, 0) {fh2, (sid1)} -> {fh2, (sid2)} CLOSE (1, 0) {fh2, (sid1)} -> {fh2, (sid2)}
Figure 3 Figure 3
This next example is similar to the second in how it passes the This next example is similar to the second in how it passes the
stateid sid2 generated by the LOCK operation to the next READ stateid sid2 generated by the LOCK operation to the next READ
operation. This allows the client to explicitly surround a single operation. This allows the client to explicitly surround a single
I/O operation with a lock and its appropriate stateid to guarantee I/O operation with a lock and its appropriate stateid to guarantee
correctness with other client locks. The example also shows how correctness with other client locks. The example also shows how
SAVEFH and RESTOREFH can save and later re-use a filehandle and SAVEFH and RESTOREFH can save and later re-use a filehandle and
stateid, passing them as the current filehandle and stateid to a READ stateid, passing them as the current filehandle and stateid to a READ
operation. operation.
PUTFH fh1 - -> {fh1, (0, 0)} PUTFH fh1 - -> {fh1, (0, 0)}
LOCK 0, 1024, (sid1) {fh1, (sid1)} -> {fh1, (sid2)} LOCK 0, 1024, (sid1) {fh1, (sid1)} -> {fh1, (sid2)}
READ (1, 0), 0, 1024 {fh1, (sid2)} -> {fh1, (sid2)} READ (1, 0), 0, 1024 {fh1, (sid2)} -> {fh1, (sid2)}
LOCKU 0, 1024, (1, 0) {fh1, (sid2)} -> {fh1, (sid3)} LOCKU 0, 1024, (1, 0) {fh1, (sid2)} -> {fh1, (sid3)}
SAVEFH {fh1, (sid3)} -> {fh1, (sid3)} SAVEFH {fh1, (sid3)} -> {fh1, (sid3)}
PUTFH fh2 {fh1, (sid3)} -> {fh2, (0, 0)} PUTFH fh2 {fh1, (sid3)} -> {fh2, (0, 0)}
WRITE (1, 0), 0, 1024 {fh2, (0, 0)} -> {fh2, (0, 0)} WRITE (1, 0), 0, 1024 {fh2, (0, 0)} -> {fh2, (0, 0)}
RESTOREFH {fh2, (0, 0)} -> {fh1, (sid3)} RESTOREFH {fh2, (0, 0)} -> {fh1, (sid3)}
READ (1, 0), 1024, 1024 {fh1, (sid3)} -> {fh1, (sid3)} READ (1, 0), 1024, 1024 {fh1, (sid3)} -> {fh1, (sid3)}
Figure 4 Figure 4
The final example shows a disallowed use of the current stateid. The The final example shows a disallowed use of the current stateid. The
client is attempting to implicitly pass anonymous special stateid, client is attempting to implicitly pass anonymous special stateid,
(0,0) to the READ operation. The server MUST return (0,0) to the READ operation. The server MUST return
NFS4ERR_BAD_STATEID in the reply to the READ operation. NFS4ERR_BAD_STATEID in the reply to the READ operation.
PUTFH fh1 - -> {fh1, (0, 0)} PUTFH fh1 - -> {fh1, (0, 0)}
READ (1, 0), 0, 1024 {fh1, (0, 0)} -> NFS4ERR_BAD_STATEID READ (1, 0), 0, 1024 {fh1, (0, 0)} -> NFS4ERR_BAD_STATEID
Figure 5 Figure 5
15.2.5. IMPLEMENTATION 15.2.5. IMPLEMENTATION
Since an error of any type may occur after only a portion of the Since an error of any type may occur after only a portion of the
operations have been evaluated, the client must be prepared to operations have been evaluated, the client must be prepared to
recover from any failure. If the source of an NFS4ERR_RESOURCE error recover from any failure. If the source of an NFS4ERR_RESOURCE error
was a complex or lengthy set of operations, it is likely that if the was a complex or lengthy set of operations, it is likely that if the
number of operations were reduced the server would be able to number of operations were reduced the server would be able to
evaluate them successfully. Therefore, the client is responsible for evaluate them successfully. Therefore, the client is responsible for
dealing with this type of complexity in recovery. dealing with this type of complexity in recovery.
The client SHOULD NOT construct a COMPOUND which mixes operations for The client SHOULD NOT construct a COMPOUND which mixes operations for
different client IDs. different client IDs.
15.3. Operation 3: ACCESS - Check Access Rights 15.3. Operation 3: ACCESS - Check Access Rights
15.3.1. SYNOPSIS 15.3.1. SYNOPSIS
(cfh), accessreq -> supported, accessrights (cfh), accessreq -> supported, accessrights
15.3.2. ARGUMENT 15.3.2. ARGUMENT
const ACCESS4_READ = 0x00000001; const ACCESS4_READ = 0x00000001;
const ACCESS4_LOOKUP = 0x00000002; const ACCESS4_LOOKUP = 0x00000002;
const ACCESS4_MODIFY = 0x00000004; const ACCESS4_MODIFY = 0x00000004;
const ACCESS4_EXTEND = 0x00000008; const ACCESS4_EXTEND = 0x00000008;
const ACCESS4_DELETE = 0x00000010; const ACCESS4_DELETE = 0x00000010;
const ACCESS4_EXECUTE = 0x00000020; const ACCESS4_EXECUTE = 0x00000020;
skipping to change at page 233, line 16 skipping to change at page 232, line 16
Therefore, the mask returned enumerating which access rights can be Therefore, the mask returned enumerating which access rights can be
determined will have the ACCESS4_DELETE value set to 0. This determined will have the ACCESS4_DELETE value set to 0. This
indicates to the client that the server was unable to check that indicates to the client that the server was unable to check that
particular access right. The ACCESS4_DELETE bit in the access mask particular access right. The ACCESS4_DELETE bit in the access mask
returned will then be ignored by the client. returned will then be ignored by the client.
15.4. Operation 4: CLOSE - Close File 15.4. Operation 4: CLOSE - Close File
15.4.1. SYNOPSIS 15.4.1. SYNOPSIS
(cfh), seqid, open_stateid -> open_stateid (cfh), seqid, open_stateid -> open_stateid
15.4.2. ARGUMENT 15.4.2. ARGUMENT
struct CLOSE4args { struct CLOSE4args {
/* CURRENT_FH: object */ /* CURRENT_FH: object */
seqid4 seqid; seqid4 seqid;
stateid4 open_stateid; stateid4 open_stateid;
}; };
15.4.3. RESULT 15.4.3. RESULT
skipping to change at page 234, line 20 skipping to change at page 233, line 20
the client and should be treated as deprecated. CLOSE "shuts down" the client and should be treated as deprecated. CLOSE "shuts down"
the state associated with all OPENs for the file by a single open- the state associated with all OPENs for the file by a single open-
owner. As noted above, CLOSE will either release all file locking owner. As noted above, CLOSE will either release all file locking
state or return an error. Therefore, the stateid returned by CLOSE state or return an error. Therefore, the stateid returned by CLOSE
is not useful for operations that follow. is not useful for operations that follow.
15.5. Operation 5: COMMIT - Commit Cached Data 15.5. Operation 5: COMMIT - Commit Cached Data
15.5.1. SYNOPSIS 15.5.1. SYNOPSIS
(cfh), offset, count -> verifier (cfh), offset, count -> verifier
15.5.2. ARGUMENT 15.5.2. ARGUMENT
struct COMMIT4args { struct COMMIT4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
offset4 offset; offset4 offset;
count4 count; count4 count;
}; };
15.5.3. RESULT 15.5.3. RESULT
skipping to change at page 235, line 25 skipping to change at page 234, line 25
verifier at each server event or instantiation that may lead to a verifier at each server event or instantiation that may lead to a
loss of uncommitted data. Most commonly this occurs when the server loss of uncommitted data. Most commonly this occurs when the server
is rebooted; however, other events at the server may result in is rebooted; however, other events at the server may result in
uncommitted data loss as well. uncommitted data loss as well.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.5.5. IMPLEMENTATION 15.5.5. IMPLEMENTATION
The COMMIT operation is similar in operation and semantics to the The COMMIT operation is similar in operation and semantics to the
POSIX fsync() [36] system call that synchronizes a file's state with POSIX fsync() [34] system call that synchronizes a file's state with
the disk (file data and metadata is flushed to disk or stable the disk (file data and metadata is flushed to disk or stable
storage). COMMIT performs the same operation for a client, flushing storage). COMMIT performs the same operation for a client, flushing
any unsynchronized data and metadata on the server to the server's any unsynchronized data and metadata on the server to the server's
disk or stable storage for the specified file. Like fsync(), it may disk or stable storage for the specified file. Like fsync(), it may
be that there is some modified data or no modified data to be that there is some modified data or no modified data to
synchronize. The data may have been synchronized by the server's synchronize. The data may have been synchronized by the server's
normal periodic buffer synchronization activity. COMMIT should normal periodic buffer synchronization activity. COMMIT should
return NFS4_OK, unless there has been an unexpected error. return NFS4_OK, unless there has been an unexpected error.
COMMIT differs from fsync() in that it is possible for the client to COMMIT differs from fsync() in that it is possible for the client to
skipping to change at page 236, line 46 skipping to change at page 235, line 46
left to the implementor. left to the implementor.
The above description applies to page-cache-based systems as well as The above description applies to page-cache-based systems as well as
buffer-cache-based systems. In those systems, the virtual memory buffer-cache-based systems. In those systems, the virtual memory
system will need to be modified instead of the buffer cache. system will need to be modified instead of the buffer cache.
15.6. Operation 6: CREATE - Create a Non-Regular File Object 15.6. Operation 6: CREATE - Create a Non-Regular File Object
15.6.1. SYNOPSIS 15.6.1. SYNOPSIS
(cfh), name, type, attrs -> (cfh), change_info, attrs_set (cfh), name, type, attrs -> (cfh), cinfo, attrset
15.6.2. ARGUMENT 15.6.2. ARGUMENT
union createtype4 switch (nfs_ftype4 type) { union createtype4 switch (nfs_ftype4 type) {
case NF4LNK: case NF4LNK:
linktext4 linkdata; linktext4 linkdata;
case NF4BLK: case NF4BLK:
case NF4CHR: case NF4CHR:
specdata4 devdata; specdata4 devdata;
case NF4SOCK: case NF4SOCK:
skipping to change at page 238, line 43 skipping to change at page 237, line 43
from the principal indicated in the RPC credentials of the call, but from the principal indicated in the RPC credentials of the call, but
the server's operating environment or filesystem semantics may the server's operating environment or filesystem semantics may
dictate other methods of derivation. Similarly, if createattrs dictate other methods of derivation. Similarly, if createattrs
includes neither the group attribute nor a group ACE, and if the includes neither the group attribute nor a group ACE, and if the
server's filesystem both supports and requires the notion of a group server's filesystem both supports and requires the notion of a group
attribute (or group ACE), the server MUST derive the group attribute attribute (or group ACE), the server MUST derive the group attribute
(or the corresponding owner ACE) for the file. This could be from (or the corresponding owner ACE) for the file. This could be from
the RPC call's credentials, such as the group principal if the the RPC call's credentials, such as the group principal if the
credentials include it (such as with AUTH_SYS), from the group credentials include it (such as with AUTH_SYS), from the group
identifier associated with the principal in the credentials (e.g., identifier associated with the principal in the credentials (e.g.,
POSIX systems have a user database [37] that has the group identifier POSIX systems have a user database [35] that has the group identifier
for every user identifier), inherited from directory the object is for every user identifier), inherited from directory the object is
created in, or whatever else the server's operating environment or created in, or whatever else the server's operating environment or
filesystem semantics dictate. This applies to the OPEN operation filesystem semantics dictate. This applies to the OPEN operation
too. too.
Conversely, it is possible the client will specify in createattrs an Conversely, it is possible the client will specify in createattrs an
owner attribute or group attribute or ACL that the principal owner attribute or group attribute or ACL that the principal
indicated the RPC call's credentials does not have permissions to indicated the RPC call's credentials does not have permissions to
create files for. The error to be returned in this instance is create files for. The error to be returned in this instance is
NFS4ERR_PERM. This applies to the OPEN operation too. NFS4ERR_PERM. This applies to the OPEN operation too.
skipping to change at page 239, line 16 skipping to change at page 238, line 16
15.6.5. IMPLEMENTATION 15.6.5. IMPLEMENTATION
If the client desires to set attribute values after the create, a If the client desires to set attribute values after the create, a
SETATTR operation can be added to the COMPOUND request so that the SETATTR operation can be added to the COMPOUND request so that the
appropriate attributes will be set. appropriate attributes will be set.
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting Recovery 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting Recovery
15.7.1. SYNOPSIS 15.7.1. SYNOPSIS
clientid -> clientid ->
15.7.2. ARGUMENT 15.7.2. ARGUMENT
struct DELEGPURGE4args { struct DELEGPURGE4args {
clientid4 clientid; clientid4 clientid;
}; };
15.7.3. RESULT 15.7.3. RESULT
struct DELEGPURGE4res { struct DELEGPURGE4res {
skipping to change at page 240, line 12 skipping to change at page 239, line 12
it received the results and committed them to the client's stable it received the results and committed them to the client's stable
storage. storage.
The server MAY support DELEGPURGE, but if it does not, it MUST NOT The server MAY support DELEGPURGE, but if it does not, it MUST NOT
support CLAIM_DELEGATE_PREV. support CLAIM_DELEGATE_PREV.
15.8. Operation 8: DELEGRETURN - Return Delegation 15.8. Operation 8: DELEGRETURN - Return Delegation
15.8.1. SYNOPSIS 15.8.1. SYNOPSIS
(cfh), stateid -> (cfh), stateid ->
15.8.2. ARGUMENT 15.8.2. ARGUMENT
struct DELEGRETURN4args { struct DELEGRETURN4args {
/* CURRENT_FH: delegated file */ /* CURRENT_FH: delegated file */
stateid4 deleg_stateid; stateid4 deleg_stateid;
}; };
15.8.3. RESULT 15.8.3. RESULT
skipping to change at page 240, line 41 skipping to change at page 239, line 41
Delegations may be returned when recalled or voluntarily (i.e., Delegations may be returned when recalled or voluntarily (i.e.,
before the server has recalled them). In either case the client must before the server has recalled them). In either case the client must
properly propagate state changed under the context of the delegation properly propagate state changed under the context of the delegation
to the server before returning the delegation. to the server before returning the delegation.
15.9. Operation 9: GETATTR - Get Attributes 15.9. Operation 9: GETATTR - Get Attributes
15.9.1. SYNOPSIS 15.9.1. SYNOPSIS
(cfh), attrbits -> attrbits, attrvals (cfh), attrbits -> attrbits, attrvals
15.9.2. ARGUMENT 15.9.2. ARGUMENT
struct GETATTR4args { struct GETATTR4args {
/* CURRENT_FH: directory or file */ /* CURRENT_FH: directory or file */
bitmap4 attr_request; bitmap4 attr_request;
}; };
15.9.3. RESULT 15.9.3. RESULT
skipping to change at page 242, line 27 skipping to change at page 241, line 27
o The OPEN_DELEGATE_WRITE delegation is revoked. o The OPEN_DELEGATE_WRITE delegation is revoked.
Unless one of the above happens very quickly, one or more Unless one of the above happens very quickly, one or more
NFS4ERR_DELAY errors will be returned if while a delegation is NFS4ERR_DELAY errors will be returned if while a delegation is
outstanding. outstanding.
15.10. Operation 10: GETFH - Get Current Filehandle 15.10. Operation 10: GETFH - Get Current Filehandle
15.10.1. SYNOPSIS 15.10.1. SYNOPSIS
(cfh) -> filehandle (cfh) -> filehandle
15.10.2. ARGUMENT 15.10.2. ARGUMENT
/* CURRENT_FH: */ /* CURRENT_FH: */
void; void;
15.10.3. RESULT 15.10.3. RESULT
struct GETFH4resok { struct GETFH4resok {
nfs_fh4 object; nfs_fh4 object;
}; };
union GETFH4res switch (nfsstat4 status) { union GETFH4res switch (nfsstat4 status) {
case NFS4_OK: case NFS4_OK:
GETFH4resok resok4; GETFH4resok resok4;
skipping to change at page 243, line 12 skipping to change at page 242, line 12
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.10.5. IMPLEMENTATION 15.10.5. IMPLEMENTATION
Operations that change the current filehandle like LOOKUP or CREATE Operations that change the current filehandle like LOOKUP or CREATE
do not automatically return the new filehandle as a result. For do not automatically return the new filehandle as a result. For
instance, if a client needs to lookup a directory entry and obtain instance, if a client needs to lookup a directory entry and obtain
its filehandle then the following request is needed. its filehandle then the following request is needed.
PUTFH (directory filehandle) PUTFH (directory filehandle)
LOOKUP (entry name) LOOKUP (entry name)
GETFH GETFH
15.11. Operation 11: LINK - Create Link to a File 15.11. Operation 11: LINK - Create Link to a File
15.11.1. SYNOPSIS 15.11.1. SYNOPSIS
(sfh), (cfh), newname -> (cfh), change_info (sfh), (cfh), newname -> (cfh), cinfo
15.11.2. ARGUMENT 15.11.2. ARGUMENT
struct LINK4args { struct LINK4args {
/* SAVED_FH: source object */ /* SAVED_FH: source object */
/* CURRENT_FH: target directory */ /* CURRENT_FH: target directory */
component4 newname; component4 newname;
}; };
15.11.3. RESULT 15.11.3. RESULT
skipping to change at page 244, line 36 skipping to change at page 243, line 36
In the case that newname is already linked to the file represented by In the case that newname is already linked to the file represented by
the saved filehandle, the server will return NFS4ERR_EXIST. the saved filehandle, the server will return NFS4ERR_EXIST.
Note that symbolic links are created with the CREATE operation. Note that symbolic links are created with the CREATE operation.
15.12. Operation 12: LOCK - Create Lock 15.12. Operation 12: LOCK - Create Lock
15.12.1. SYNOPSIS 15.12.1. SYNOPSIS
(cfh) locktype, reclaim, offset, length, locker -> stateid (cfh) locktype, reclaim, offset, length, locker -> stateid
15.12.2. ARGUMENT 15.12.2. ARGUMENT
enum nfs_lock_type4 { enum nfs_lock_type4 {
READ_LT = 1, READ_LT = 1,
WRITE_LT = 2, WRITE_LT = 2,
READW_LT = 3, /* blocking read */ READW_LT = 3, /* blocking read */
WRITEW_LT = 4 /* blocking write */ WRITEW_LT = 4 /* blocking write */
}; };
/* /*
skipping to change at page 248, line 12 skipping to change at page 247, line 12
LOCK operation where the server is implementing mandatory locking LOCK operation where the server is implementing mandatory locking
semantics MUST result in the recall of all such delegations. The semantics MUST result in the recall of all such delegations. The
LOCK operation may not be granted until all such delegations are LOCK operation may not be granted until all such delegations are
returned or revoked. Except where this happens very quickly, one or returned or revoked. Except where this happens very quickly, one or
more NFS4ERR_DELAY errors will be returned to requests made while the more NFS4ERR_DELAY errors will be returned to requests made while the
delegation remains outstanding. delegation remains outstanding.
The locker argument specifies the lock-owner that is associated with The locker argument specifies the lock-owner that is associated with
the LOCK request. The locker4 structure is a switched union that the LOCK request. The locker4 structure is a switched union that
indicates whether the client has already created byte-range locking indicates whether the client has already created byte-range locking
state associated with the current open file and lock-owner. In the state associated with the current open file and lock-owner. There
case in which it has, the argument is just a stateid representing the are multiple cases to be considered, corresponding to possible
set of locks associated with that open file and lock-owner, together combinations of whether locking state has been created for the
with a lock_seqid value that MAY be any value and MUST be ignored by current open file and lock-owner, and whether the boolean
the server. In the case where no byte-range locking state has been new_lock_owner is set. In all of the cases, there is a lock_seqid
established, or the client does not have the stateid available, the specified, whether the lock-owner is specified explicitly or
argument contains the stateid of the open file with which this lock implicitly. This seqid value is used for checking lockowner
is to be associated, together with the lock-owner with which the lock sequencing/replay issues. When the given lockowner is not known to
is to be associated. The open_to_lock_owner case covers the very the server, this establishes an initial sequence value for the new
first lock done by a lock-owner for a given open file and offers a lockowner.
method to use the established state of the open_stateid to transition
to the use of a lock stateid. o In the case in which the state has been created and the boolean is
false, the only part of the argument other than lock_seqid is just
a stateid representing the set of locks associated with that open
file and lock-owner.
o In the case in which the state has been created and the boolean is
true, the server rejects the request with the error
NFS4ERR_BADSEQ. The only exception is where there is a
retransmission of a previous request in which the boolean was
true. In this case, the lock_seqid will match the original
request and the response will reflect the final case, below.
o In the case where no byte-range locking state has been established
and the boolean is true, the argument contains an
open_to_lock_owner structure which specifies the stateid of the
open file and the lock-owner to be used for the lock. Note that
although the open-owner is not given explicitly, the open_seqid
associated with it is used to check for open-owner sequencing
issues. This case provides a method to use the established state
of the open_stateid to transition to the use of a lock stateid.
15.13. Operation 13: LOCKT - Test For Lock 15.13. Operation 13: LOCKT - Test For Lock
15.13.1. SYNOPSIS 15.13.1. SYNOPSIS
(cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED -> (cfh) locktype, offset, length, owner -> {void, NFS4ERR_DENIED ->
owner} owner}
15.13.2. ARGUMENT 15.13.2. ARGUMENT
struct LOCKT4args { struct LOCKT4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
nfs_lock_type4 locktype; nfs_lock_type4 locktype;
offset4 offset; offset4 offset;
length4 length; length4 length;
lock_owner4 owner; lock_owner4 owner;
}; };
skipping to change at page 250, line 13 skipping to change at page 249, line 24
provided to the server. provided to the server.
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose
(see Section 15.12.5)) to handle LOCK requests locally. In such a (see Section 15.12.5)) to handle LOCK requests locally. In such a
case, LOCKT requests will similarly be handled locally. case, LOCKT requests will similarly be handled locally.
15.14. Operation 14: LOCKU - Unlock File 15.14. Operation 14: LOCKU - Unlock File
15.14.1. SYNOPSIS 15.14.1. SYNOPSIS
(cfh) type, seqid, stateid, offset, length -> stateid (cfh) type, seqid, stateid, offset, length -> stateid
15.14.2. ARGUMENT 15.14.2. ARGUMENT
struct LOCKU4args { struct LOCKU4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
nfs_lock_type4 locktype; nfs_lock_type4 locktype;
seqid4 seqid; seqid4 seqid;
stateid4 lock_stateid; stateid4 lock_stateid;
offset4 offset; offset4 offset;
length4 length; length4 length;
skipping to change at page 251, line 13 skipping to change at page 250, line 27
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.14.5. IMPLEMENTATION 15.14.5. IMPLEMENTATION
If the area to be unlocked does not correspond exactly to a lock If the area to be unlocked does not correspond exactly to a lock
actually held by the lock-owner the server may return the error actually held by the lock-owner the server may return the error
NFS4ERR_LOCK_RANGE. This includes the case in which the area is not NFS4ERR_LOCK_RANGE. This includes the case in which the area is not
locked, where the area is a sub-range of the area locked, where it locked, where the area is a sub-range of the area locked, where it
overlaps the area locked without matching exactly or the area overlaps the area locked without matching exactly or the area
specified includes multiple locks held by the lock-owner. In all of specified includes multiple locks held by the lock-owner. In all of
these cases, allowed by POSIX locking [35] semantics, a client these cases, allowed by POSIX locking [33] semantics, a client
receiving this error, should if it desires support for such receiving this error, should if it desires support for such
operations, simulate the operation using LOCKU on ranges operations, simulate the operation using LOCKU on ranges
corresponding to locks it actually holds, possibly followed by LOCK corresponding to locks it actually holds, possibly followed by LOCK
requests for the sub-ranges not being unlocked. requests for the sub-ranges not being unlocked.
When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose When a client holds an OPEN_DELEGATE_WRITE delegation, it may choose
(see Section 15.12.5)) to handle LOCK requests locally. In such a (see Section 15.12.5)) to handle LOCK requests locally. In such a
case, LOCKU requests will similarly be handled locally. case, LOCKU requests will similarly be handled locally.
15.15. Operation 15: LOOKUP - Lookup Filename 15.15. Operation 15: LOOKUP - Lookup Filename
15.15.1. SYNOPSIS 15.15.1. SYNOPSIS
(cfh), component -> (cfh) (cfh), component -> (cfh)
15.15.2. ARGUMENT 15.15.2. ARGUMENT
struct LOOKUP4args { struct LOOKUP4args {
/* CURRENT_FH: directory */ /* CURRENT_FH: directory */
component4 objname; component4 objname;
}; };
15.15.3. RESULT 15.15.3. RESULT
skipping to change at page 252, line 18 skipping to change at page 251, line 34
If the component is of zero length, NFS4ERR_INVAL will be returned. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 12.3 for further discussion. and name checks. See Section 12.3 for further discussion.
15.15.5. IMPLEMENTATION 15.15.5. IMPLEMENTATION
If the client wants to achieve the effect of a multi-component If the client wants to achieve the effect of a multi-component
lookup, it may construct a COMPOUND request such as (and obtain each lookup, it may construct a COMPOUND request such as (and obtain each
filehandle): filehandle):
PUTFH (directory filehandle) PUTFH (directory filehandle)
LOOKUP "pub" LOOKUP "pub"
GETFH GETFH
LOOKUP "foo" LOOKUP "foo"
GETFH GETFH
LOOKUP "bar" LOOKUP "bar"
GETFH GETFH
NFSv4 servers depart from the semantics of previous NFS versions in NFSv4 servers depart from the semantics of previous NFS versions in
allowing LOOKUP requests to cross mountpoints on the server. The allowing LOOKUP requests to cross mountpoints on the server. The
client can detect a mountpoint crossing by comparing the fsid client can detect a mountpoint crossing by comparing the fsid
attribute of the directory with the fsid attribute of the directory attribute of the directory with the fsid attribute of the directory
looked up. If the fsids are different then the new directory is a looked up. If the fsids are different then the new directory is a
server mountpoint. UNIX clients that detect a mountpoint crossing server mountpoint. UNIX clients that detect a mountpoint crossing
will need to mount the server's filesystem. This needs to be done to will need to mount the server's filesystem. This needs to be done to
maintain the file object identity checking mechanisms common to UNIX maintain the file object identity checking mechanisms common to UNIX
clients. clients.
skipping to change at page 253, line 11 skipping to change at page 252, line 28
are modified by symbolic links encountered during the lookup process. are modified by symbolic links encountered during the lookup process.
If the current filehandle supplied is not a directory but a symbolic If the current filehandle supplied is not a directory but a symbolic
link, the error NFS4ERR_SYMLINK is returned as the error. For all link, the error NFS4ERR_SYMLINK is returned as the error. For all
other non-directory file types, the error NFS4ERR_NOTDIR is returned. other non-directory file types, the error NFS4ERR_NOTDIR is returned.
15.16. Operation 16: LOOKUPP - Lookup Parent Directory 15.16. Operation 16: LOOKUPP - Lookup Parent Directory
15.16.1. SYNOPSIS 15.16.1. SYNOPSIS
(cfh) -> (cfh) (cfh) -> (cfh)
15.16.2. ARGUMENT 15.16.2. ARGUMENT
/* CURRENT_FH: object */ /* CURRENT_FH: object */
void; void;
15.16.3. RESULT 15.16.3. RESULT
struct LOOKUPP4res { struct LOOKUPP4res {
/* CURRENT_FH: directory */ /* CURRENT_FH: directory */
nfsstat4 status; nfsstat4 status;
}; };
15.16.4. DESCRIPTION 15.16.4. DESCRIPTION
skipping to change at page 253, line 45 skipping to change at page 253, line 16
As for LOOKUP, LOOKUPP will also cross mountpoints. As for LOOKUP, LOOKUPP will also cross mountpoints.
If the current filehandle is not a directory or named attribute If the current filehandle is not a directory or named attribute
directory, the error NFS4ERR_NOTDIR is returned. directory, the error NFS4ERR_NOTDIR is returned.
15.17. Operation 17: NVERIFY - Verify Difference in Attributes 15.17. Operation 17: NVERIFY - Verify Difference in Attributes
15.17.1. SYNOPSIS 15.17.1. SYNOPSIS
(cfh), fattr -> - (cfh), fattr -> -
15.17.2. ARGUMENT 15.17.2. ARGUMENT
struct NVERIFY4args { struct NVERIFY4args {
/* CURRENT_FH: object */ /* CURRENT_FH: object */
fattr4 obj_attributes; fattr4 obj_attributes;
}; };
15.17.3. RESULT 15.17.3. RESULT
skipping to change at page 254, line 35 skipping to change at page 253, line 48
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.17.5. IMPLEMENTATION 15.17.5. IMPLEMENTATION
This operation is useful as a cache validation operator. If the This operation is useful as a cache validation operator. If the
object to which the attributes belong has changed then the following object to which the attributes belong has changed then the following
operations may obtain new data associated with that object. For operations may obtain new data associated with that object. For
instance, to check if a file has been changed and obtain new data if instance, to check if a file has been changed and obtain new data if
it has: it has:
PUTFH (public) PUTFH (public)
LOOKUP "foobar" LOOKUP "foobar"
NVERIFY attrbits attrs NVERIFY attrbits attrs
READ 0 32767 READ 0 32767
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 operation and the server does not support that attribute for the
filesystem object, the error NFS4ERR_ATTRNOTSUPP is returned to the filesystem 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 write-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.
15.18. Operation 18: OPEN - Open a Regular File 15.18. Operation 18: OPEN - Open a Regular File
15.18.1. SYNOPSIS 15.18.1. SYNOPSIS
(cfh), seqid, share_access, share_deny, owner, openhow, claim -> (cfh), seqid, share_access, share_deny, owner, openhow, claim ->
(cfh), stateid, cinfo, rflags, attrset, delegation (cfh), stateid, cinfo, rflags, attrset, delegation
15.18.2. ARGUMENT 15.18.2. ARGUMENT
/* /*
* Various definitions for OPEN * Various definitions for OPEN
*/ */
enum createmode4 { enum createmode4 {
UNCHECKED4 = 0, UNCHECKED4 = 0,
GUARDED4 = 1, GUARDED4 = 1,
EXCLUSIVE4 = 2 EXCLUSIVE4 = 2
skipping to change at page 261, line 45 skipping to change at page 260, line 51
reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed. reclaim (CLAIM_PREVIOUS) case, in which a delegation type is claimed.
In this case, delegation will always be granted, although the server In this case, delegation will always be granted, although the server
may specify an immediate recall in the delegation structure. may specify an immediate recall in the delegation structure.
The rflags returned by a successful OPEN allow the server to return The rflags returned by a successful OPEN allow the server to return
information governing how the open file is to be handled. information governing how the open file is to be handled.
OPEN4_RESULT_CONFIRM indicates that the client MUST execute an OPEN4_RESULT_CONFIRM indicates that the client MUST execute an
OPEN_CONFIRM operation before using the open file. OPEN_CONFIRM operation before using the open file.
OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking OPEN4_RESULT_LOCKTYPE_POSIX indicates the server's file locking
behavior supports the complete set of Posix locking techniques [35]. behavior supports the complete set of Posix locking techniques [33].
From this the client can choose to manage file locking state in a way From this the client can choose to manage file locking state in a way
to handle a mis-match of file locking management. to handle a mis-match of file locking management.
If the component is of zero length, NFS4ERR_INVAL will be returned. If the component is of zero length, NFS4ERR_INVAL will be returned.
The component is also subject to the normal UTF-8, character support, The component is also subject to the normal UTF-8, character support,
and name checks. See Section 12.3 for further discussion. and name checks. See Section 12.3 for further discussion.
When an OPEN is done and the specified open-owner already has the When an OPEN is done and the specified open-owner already has the
resulting filehandle open, the result is to "OR" together the new resulting filehandle open, the result is to "OR" together the new
share and deny status together with the existing status. In this share and deny status together with the existing status. In this
skipping to change at page 262, line 38 skipping to change at page 261, line 45
does not have authorization to create files for, then the server may does not have authorization to create files for, then the server may
return NFS4ERR_PERM. return NFS4ERR_PERM.
In the case of a OPEN which specifies a size of zero (e.g., In the case of a OPEN which specifies a size of zero (e.g.,
truncation) and the file has named attributes, the named attributes truncation) and the file has named attributes, the named attributes
are left as is. They are not removed. are left as is. They are not removed.
15.18.6. IMPLEMENTATION 15.18.6. IMPLEMENTATION
The OPEN operation contains support for EXCLUSIVE4 create. The The OPEN operation contains support for EXCLUSIVE4 create. The
mechanism is similar to the support in NFSv3 [14]. As in NFSv3, this mechanism is similar to the support in NFSv3 [13]. As in NFSv3, this
mechanism provides reliable exclusive creation. Exclusive create is mechanism provides reliable exclusive creation. Exclusive create is
invoked when the how parameter is EXCLUSIVE4. In this case, the invoked when the how parameter is EXCLUSIVE4. In this case, the
client provides a verifier that can reasonably be expected to be client provides a verifier that can reasonably be expected to be
unique. A combination of a client identifier, perhaps the client unique. A combination of a client identifier, perhaps the client
network address, and a unique number generated by the client, perhaps network address, and a unique number generated by the client, perhaps
the RPC transaction identifier, may be appropriate. the RPC transaction identifier, may be appropriate.
If the object does not exist, the server creates the object and If the object does not exist, the server creates the object and
stores the verifier in stable storage. For filesystems that do not stores the verifier in stable storage. For filesystems that do not
provide a mechanism for the storage of arbitrary file attributes, the provide a mechanism for the storage of arbitrary file attributes, the
skipping to change at page 265, line 9 skipping to change at page 264, line 15
Simply waiting for the lease on the file to expire is insufficient Simply waiting for the lease on the file to expire is insufficient
because the server may maintain the state indefinitely as long as because the server may maintain the state indefinitely as long as
another client does not attempt to make a conflicting access to the another client does not attempt to make a conflicting access to the
same file. same file.
15.19. Operation 19: OPENATTR - Open Named Attribute Directory 15.19. Operation 19: OPENATTR - Open Named Attribute Directory
15.19.1. SYNOPSIS 15.19.1. SYNOPSIS
(cfh) createdir -> (cfh) (cfh) createdir -> (cfh)
15.19.2. ARGUMENT 15.19.2. ARGUMENT
struct OPENATTR4args { struct OPENATTR4args {
/* CURRENT_FH: object */ /* CURRENT_FH: object */
bool createdir; bool createdir;
}; };
15.19.3. RESULT 15.19.3. RESULT
skipping to change at page 266, line 9 skipping to change at page 265, line 16
15.19.5. IMPLEMENTATION 15.19.5. IMPLEMENTATION
If the server does not support named attributes for the current If the server does not support named attributes for the current
filehandle, an error of NFS4ERR_NOTSUPP will be returned to the filehandle, an error of NFS4ERR_NOTSUPP will be returned to the
client. client.
15.20. Operation 20: OPEN_CONFIRM - Confirm Open 15.20. Operation 20: OPEN_CONFIRM - Confirm Open
15.20.1. SYNOPSIS 15.20.1. SYNOPSIS
(cfh), seqid, stateid -> stateid (cfh), seqid, stateid -> stateid
15.20.2. ARGUMENT 15.20.2. ARGUMENT
struct OPEN_CONFIRM4args { struct OPEN_CONFIRM4args {
/* CURRENT_FH: opened file */ /* CURRENT_FH: opened file */
stateid4 open_stateid; stateid4 open_stateid;
seqid4 seqid; seqid4 seqid;
}; };
15.20.3. RESULT 15.20.3. RESULT
skipping to change at page 267, line 20 skipping to change at page 266, line 28
an implementation choice. The time period should certainly be no an implementation choice. The time period should certainly be no
less than the lease time plus any grace period the server wishes to less than the lease time plus any grace period the server wishes to
implement beyond a lease time. The OPEN_CONFIRM operation allows the implement beyond a lease time. The OPEN_CONFIRM operation allows the
server to safely dispose of unused open_owner4 data structures. server to safely dispose of unused open_owner4 data structures.
In the case that a client issues an OPEN operation and the server no In the case that a client issues an OPEN operation and the server no
longer has a record of the open_owner4, the server needs to ensure longer has a record of the open_owner4, the server needs to ensure
that this is a new OPEN and not a replay or retransmission. that this is a new OPEN and not a replay or retransmission.
Servers must not require confirmation on OPENs that grant delegations Servers must not require confirmation on OPENs that grant delegations
or are doing reclaim operations. See Section 9.1.9 for details. The or are doing reclaim operations. See Section 9.1.10 for details.
server can easily avoid this by noting whether it has disposed of one The server can easily avoid this by noting whether it has disposed of
open_owner4 for the given client ID. If the server does not support one open_owner4 for the given client ID. If the server does not
delegation, it might simply maintain a single bit that notes whether support delegation, it might simply maintain a single bit that notes
any open_owner4 (for any client) has been disposed of. whether any open_owner4 (for any client) has been disposed of.
The server must hold unconfirmed OPEN state until one of three events The server must hold unconfirmed OPEN state until one of three events
occur. First, the client sends an OPEN_CONFIRM request with the occur. First, the client sends an OPEN_CONFIRM request with the
appropriate sequence id and stateid within the lease period. In this appropriate sequence id and stateid within the lease period. In this
case, the OPEN state on the server goes to confirmed, and the case, the OPEN state on the server goes to confirmed, and the
open_owner4 on the server is fully established. open_owner4 on the server is fully established.
Second, the client sends another OPEN request with a sequence id that Second, the client sends another OPEN request with a sequence id that
is incorrect for the open_owner4 (out of sequence). In this case, is incorrect for the open_owner4 (out of sequence). In this case,
the server assumes the second OPEN request is valid and the first one the server assumes the second OPEN request is valid and the first one
is a replay. The server cancels the OPEN state of the first OPEN is a replay. The server cancels the OPEN state of the first OPEN
request, establishes an unconfirmed OPEN state for the second OPEN request, establishes an unconfirmed OPEN state for the second OPEN
request, and responds to the second OPEN request with an indication request, and responds to the second OPEN request with an indication
that an OPEN_CONFIRM is needed. The process then repeats itself. that an OPEN_CONFIRM is needed. The process then repeats itself.
While there is a potential for a denial of service attack on the While there is a potential for a denial of service attack on the
client, it is mitigated if the client and server require the use of a client, it is mitigated if the client and server require the use of a
security flavor based on Kerberos V5, LIPKEY, or some other flavor security flavor based on Kerberos V5 or some other flavor that uses
that uses cryptography. cryptography.
What if the server is in the unconfirmed OPEN state for a given What if the server is in the unconfirmed OPEN state for a given
open_owner4, and it receives an operation on the open_owner4 that has open_owner4, and it receives an operation on the open_owner4 that has
a stateid but the operation is not OPEN, or it is OPEN_CONFIRM but a stateid but the operation is not OPEN, or it is OPEN_CONFIRM but
with the wrong stateid? Then, even if the seqid is correct, the with the wrong stateid? Then, even if the seqid is correct, the
server returns NFS4ERR_BAD_STATEID, because the server assumes the server returns NFS4ERR_BAD_STATEID, because the server assumes the
operation is a replay: if the server has no established OPEN state, operation is a replay: if the server has no established OPEN state,
then there is no way, for example, a LOCK operation could be valid. then there is no way, for example, a LOCK operation could be valid.
Third, neither of the two aforementioned events occur for the Third, neither of the two aforementioned events occur for the
open_owner4 within the lease period. In this case, the OPEN state is open_owner4 within the lease period. In this case, the OPEN state is
canceled and disposal of the open_owner4 can occur. canceled and disposal of the open_owner4 can occur.
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access
15.21.1. SYNOPSIS 15.21.1. SYNOPSIS
(cfh), stateid, seqid, access, deny -> stateid (cfh), stateid, seqid, access, deny -> stateid
15.21.2. ARGUMENT 15.21.2. ARGUMENT
struct OPEN_DOWNGRADE4args { struct OPEN_DOWNGRADE4args {
/* CURRENT_FH: opened file */ /* CURRENT_FH: opened file */
stateid4 open_stateid; stateid4 open_stateid;
seqid4 seqid; seqid4 seqid;
uint32_t share_access; uint32_t share_access;
uint32_t share_deny; uint32_t share_deny;
}; };
skipping to change at page 269, line 20 skipping to change at page 268, line 27
As the OPEN_DOWNGRADE may change a file to be not-open-for-write and As the OPEN_DOWNGRADE may change a file to be not-open-for-write and
a write byte-range lock might be held, the server may have to reject a write byte-range lock might be held, the server may have to reject
the OPEN_DOWNGRADE with a NFS4ERR_LOCKS_HELD. the OPEN_DOWNGRADE with a NFS4ERR_LOCKS_HELD.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.22. Operation 22: PUTFH - Set Current Filehandle 15.22. Operation 22: PUTFH - Set Current Filehandle
15.22.1. SYNOPSIS 15.22.1. SYNOPSIS
filehandle -> (cfh) filehandle -> (cfh)
15.22.2. ARGUMENT 15.22.2. ARGUMENT
struct PUTFH4args { struct PUTFH4args {
nfs_fh4 object; nfs_fh4 object;
}; };
15.22.3. RESULT 15.22.3. RESULT
struct PUTFH4res { struct PUTFH4res {
skipping to change at page 270, line 14 skipping to change at page 269, line 18
15.22.5. IMPLEMENTATION 15.22.5. IMPLEMENTATION
Commonly used as the first operator in an NFS request to set the Commonly used as the first operator in an NFS request to set the
context for following operations. context for following operations.
15.23. Operation 23: PUTPUBFH - Set Public Filehandle 15.23. Operation 23: PUTPUBFH - Set Public Filehandle
15.23.1. SYNOPSIS 15.23.1. SYNOPSIS
- -> (cfh) - -> (cfh)
15.23.2. ARGUMENT 15.23.2. ARGUMENT
void; void;
15.23.3. RESULT 15.23.3. RESULT
struct PUTPUBFH4res { struct PUTPUBFH4res {
/* CURRENT_FH: public fh */ /* CURRENT_FH: public fh */
nfsstat4 status; nfsstat4 status;
}; };
15.23.4. DESCRIPTION 15.23.4. DESCRIPTION
Replaces the current filehandle with the filehandle that represents Replaces the current filehandle with the filehandle that represents
the public filehandle of the server's name space. This filehandle the public filehandle of the server's name space. This filehandle
may be different from the "root" filehandle which may be associated may be different from the "root" filehandle which may be associated
with some other directory on the server. with some other directory on the server.
The public filehandle represents the concepts embodied in [23], [24], The public filehandle represents the concepts embodied in [21], [22],
[38]. The intent for NFSv4 is that the public filehandle [36]. The intent for NFSv4 is that the public filehandle
(represented by the PUTPUBFH operation) be used as a method of (represented by the PUTPUBFH operation) be used as a method of
providing WebNFS server compatibility with NFSv2 and NFSv3. providing WebNFS server compatibility with NFSv2 and NFSv3.
The public filehandle and the root filehandle (represented by the The public filehandle and the root filehandle (represented by the
PUTROOTFH operation) should be equivalent. If the public and root PUTROOTFH operation) should be equivalent. If the public and root
filehandles are not equivalent, then the public filehandle MUST be a filehandles are not equivalent, then the public filehandle MUST be a
descendant of the root filehandle. descendant of the root filehandle.
15.23.5. IMPLEMENTATION 15.23.5. IMPLEMENTATION
Used as the first operator in an NFS request to set the context for Used as the first operator in an NFS request to set the context for
following operations. following operations.
With the NFSv2 and 3 public filehandle, the client is able to specify With the NFSv2 and 3 public filehandle, the client is able to specify
whether the path name provided in the LOOKUP should be evaluated as whether the path name provided in the LOOKUP should be evaluated as
either an absolute path relative to the server's root or relative to either an absolute path relative to the server's root or relative to
the public filehandle. [38] contains further discussion of the the public filehandle. [36] contains further discussion of the
functionality. With NFSv4, that type of specification is not functionality. With NFSv4, that type of specification is not
directly available in the LOOKUP operation. The reason for this is directly available in the LOOKUP operation. The reason for this is
because the component separators needed to specify absolute vs. because the component separators needed to specify absolute vs.
relative are not allowed in NFSv4. Therefore, the client is relative are not allowed in NFSv4. Therefore, the client is
responsible for constructing its request such that the use of either responsible for constructing its request such that the use of either
PUTROOTFH or PUTPUBFH are used to signify absolute or relative PUTROOTFH or PUTPUBFH are used to signify absolute or relative
evaluation of an NFS URL respectively. evaluation of an NFS URL respectively.
Note that there are warnings mentioned in [38] with respect to the Note that there are warnings mentioned in [36] with respect to the
use of absolute evaluation and the restrictions the server may place use of absolute evaluation and the restrictions the server may place
on that evaluation with respect to how much of its namespace has been on that evaluation with respect to how much of its namespace has been
made available. These same warnings apply to NFSv4. It is likely, made available. These same warnings apply to NFSv4. It is likely,
therefore that because of server implementation details, an NFSv3 therefore that because of server implementation details, an NFSv3
absolute public filehandle lookup may behave differently than an absolute public filehandle lookup may behave differently than an
NFSv4 absolute resolution. NFSv4 absolute resolution.
There is a form of security negotiation as described in [39] that There is a form of security negotiation as described in [37] that
uses the public filehandle a method of employing SNEGO. This method uses the public filehandle a method of employing SNEGO. This method
is not available with NFSv4 as filehandles are not overloaded with is not available with NFSv4 as filehandles are not overloaded with
special meaning and therefore do not provide the same framework as special meaning and therefore do not provide the same framework as
NFSv2 and NFSv3. Clients should therefore use the security NFSv2 and NFSv3. Clients should therefore use the security
negotiation mechanisms described in this RFC. negotiation mechanisms described in this RFC.
15.24. Operation 24: PUTROOTFH - Set Root Filehandle 15.24. Operation 24: PUTROOTFH - Set Root Filehandle
15.24.1. SYNOPSIS 15.24.1. SYNOPSIS
- -> (cfh) - -> (cfh)
15.24.2. ARGUMENT 15.24.2. ARGUMENT
void; void;
15.24.3. RESULT 15.24.3. RESULT
struct PUTROOTFH4res { struct PUTROOTFH4res {
/* CURRENT_FH: root fh */ /* CURRENT_FH: root fh */
nfsstat4 status; nfsstat4 status;
}; };
15.24.4. DESCRIPTION 15.24.4. DESCRIPTION
skipping to change at page 272, line 21 skipping to change at page 271, line 28
15.24.5. IMPLEMENTATION 15.24.5. IMPLEMENTATION
Commonly used as the first operator in an NFS request to set the Commonly used as the first operator in an NFS request to set the
context for following operations. context for following operations.
15.25. Operation 25: READ - Read from File 15.25. Operation 25: READ - Read from File
15.25.1. SYNOPSIS 15.25.1. SYNOPSIS
(cfh), stateid, offset, count -> eof, data (cfh), stateid, offset, count -> eof, data
15.25.2. ARGUMENT 15.25.2. ARGUMENT
struct READ4args { struct READ4args {
/* CURRENT_FH: file */ /* CURRENT_FH: file */
stateid4 stateid; stateid4 stateid;
offset4 offset; offset4 offset;
count4 count; count4 count;
}; };
skipping to change at page 274, line 38 skipping to change at page 274, line 4
proceed until that delegation is returned or revoked. Except where proceed until that delegation is returned or revoked. Except where
this happens very quickly, one or more NFS4ERR_DELAY errors will be this happens very quickly, one or more NFS4ERR_DELAY errors will be
returned to requests made while the delegation remains outstanding. returned to requests made while the delegation remains outstanding.
Normally, delegations will not be recalled as a result of a READ Normally, delegations will not be recalled as a result of a READ
operation since the recall will occur as a result of an earlier OPEN. operation since the recall will occur as a result of an earlier OPEN.
However, since it is possible for a READ to be done with a special However, since it is possible for a READ to be done with a special
stateid, the server needs to check for this case even though the stateid, the server needs to check for this case even though the
client should have done an OPEN previously. client should have done an OPEN previously.
15.26. Operation 26: READDIR - Read Directory 15.26. Operation 26: READDIR - Read Directory
15.26.1. SYNOPSIS 15.26.1. SYNOPSIS
(cfh), cookie, cookieverf, dircount, maxcount, attr_request -> (cfh), cookie, cookieverf, dircount, maxcount, attr_request ->
cookieverf { cookie, name, attrs } cookieverf { cookie, name, attrs }
15.26.2. ARGUMENT 15.26.2. ARGUMENT
struct READDIR4args { struct READDIR4args {
/* CURRENT_FH: directory */ /* CURRENT_FH: directory */
nfs_cookie4 cookie; nfs_cookie4 cookie;
verifier4 cookieverf; verifier4 cookieverf;
count4 dircount; count4 dircount;
count4 maxcount; count4 maxcount;
bitmap4 attr_request; bitmap4 attr_request;
skipping to change at page 278, line 21 skipping to change at page 277, line 28
Since some servers will not be returning "." and ".." entries as has Since some servers will not be returning "." and ".." entries as has
been done with previous versions of the NFS protocol, the client that been done with previous versions of the NFS protocol, the client that
requires these entries be present in READDIR responses must fabricate requires these entries be present in READDIR responses must fabricate
them. them.
15.27. Operation 27: READLINK - Read Symbolic Link 15.27. Operation 27: READLINK - Read Symbolic Link
15.27.1. SYNOPSIS 15.27.1. SYNOPSIS
(cfh) -> linktext (cfh) -> linktext
15.27.2. ARGUMENT 15.27.2. ARGUMENT
/* CURRENT_FH: symlink */ /* CURRENT_FH: symlink */
void; void;
15.27.3. RESULT 15.27.3. RESULT
struct READLINK4resok { struct READLINK4resok {
linktext4 link; linktext4 link;
}; };
union READLINK4res switch (nfsstat4 status) { union READLINK4res switch (nfsstat4 status) {
case NFS4_OK: case NFS4_OK:
READLINK4resok resok4; READLINK4resok resok4;
skipping to change at page 279, line 24 skipping to change at page 278, line 34
data in the symbolic link. data in the symbolic link.
The READLINK operation is only allowed on objects of type NF4LNK. The READLINK operation is only allowed on objects of type NF4LNK.
The server should return the error, NFS4ERR_INVAL, if the object is The server should return the error, NFS4ERR_INVAL, if the object is
not of type, NF4LNK. not of type, NF4LNK.
15.28. Operation 28: REMOVE - Remove Filesystem Object 15.28. Operation 28: REMOVE - Remove Filesystem Object
15.28.1. SYNOPSIS 15.28.1. SYNOPSIS
(cfh), filename -> change_info (cfh), filename -> change_info
15.28.2. ARGUMENT 15.28.2. ARGUMENT
struct REMOVE4args { struct REMOVE4args {
/* CURRENT_FH: directory */ /* CURRENT_FH: directory */
component4 target; component4 target;
}; };
15.28.3. RESULT 15.28.3. RESULT
skipping to change at page 280, line 23 skipping to change at page 279, line 42
target is also subject to the normal UTF-8, character support, and target is also subject to the normal UTF-8, character support, and
name checks. See Section 12.3 for further discussion. name checks. See Section 12.3 for further discussion.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.28.5. IMPLEMENTATION 15.28.5. IMPLEMENTATION
NFSv3 required a different operator RMDIR for directory removal and NFSv3 required a different operator RMDIR for directory removal and
REMOVE for non-directory removal. This allowed clients to skip REMOVE for non-directory removal. This allowed clients to skip
checking the file type when being passed a non-directory delete checking the file type when being passed a non-directory delete
system call (e.g., unlink() [40] in POSIX) to remove a directory, as system call (e.g., unlink() [38] in POSIX) to remove a directory, as
well as the converse (e.g., a rmdir() on a non-directory) because well as the converse (e.g., a rmdir() on a non-directory) because
they knew the server would check the file type. NFSv4 REMOVE can be they knew the server would check the file type. NFSv4 REMOVE can be
used to delete any directory entry independent of its file type. The used to delete any directory entry independent of its file type. The
implementor of an NFSv4 client's entry points from the unlink() and implementor of an NFSv4 client's entry points from the unlink() and
rmdir() system calls should first check the file type against the rmdir() system calls should first check the file type against the
types the system call is allowed to remove before issuing a REMOVE. types the system call is allowed to remove before issuing a REMOVE.
Alternatively, the implementor can produce a COMPOUND call that Alternatively, the implementor can produce a COMPOUND call that
includes a LOOKUP/VERIFY sequence to verify the file type before a includes a LOOKUP/VERIFY sequence to verify the file type before a
REMOVE operation in the same COMPOUND call. REMOVE operation in the same COMPOUND call.
skipping to change at page 281, line 15 skipping to change at page 280, line 33
o If the file was not opened with OPEN4_SHARE_DENY_WRITE or o If the file was not opened with OPEN4_SHARE_DENY_WRITE or
OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's
directory entry. However, until last CLOSE of the file, the directory entry. However, until last CLOSE of the file, the
server MAY continue to allow access to the file via its server MAY continue to allow access to the file via its
filehandle. filehandle.
15.29. Operation 29: RENAME - Rename Directory Entry 15.29. Operation 29: RENAME - Rename Directory Entry
15.29.1. SYNOPSIS 15.29.1. SYNOPSIS
(sfh), oldname, (cfh), newname -> source_change_info, (sfh), oldname, (cfh), newname -> source_cinfo, target_cinfo
target_change_info
15.29.2. ARGUMENT 15.29.2. ARGUMENT
struct RENAME4args { struct RENAME4args {
/* SAVED_FH: source directory */ /* SAVED_FH: source directory */
component4 oldname; component4 oldname;
/* CURRENT_FH: target directory */ /* CURRENT_FH: target directory */
component4 newname; component4 newname;
}; };
skipping to change at page 283, line 10 skipping to change at page 282, line 36
alias for the source directory will be checked for. Such servers alias for the source directory will be checked for. Such servers
will return the error NFS4ERR_INVAL in these cases. will return the error NFS4ERR_INVAL in these cases.
If either of the source or target filehandles are not directories, If either of the source or target filehandles are not directories,
the server will return NFS4ERR_NOTDIR. the server will return NFS4ERR_NOTDIR.
15.30. Operation 30: RENEW - Renew a Lease 15.30. Operation 30: RENEW - Renew a Lease
15.30.1. SYNOPSIS 15.30.1. SYNOPSIS
clientid -> () clientid -> ()
15.30.2. ARGUMENT 15.30.2. ARGUMENT
struct RENEW4args { struct RENEW4args {
clientid4 clientid; clientid4 clientid;
}; };
15.30.3. RESULT 15.30.3. RESULT
struct RENEW4res { struct RENEW4res {
skipping to change at page 284, line 24 skipping to change at page 283, line 51
is still open by that principal, and the flavor, mechanism, and is still open by that principal, and the flavor, mechanism, and
service of RENEW match that of the previous OPEN. service of RENEW match that of the previous OPEN.
The server MUST reject a RENEW that does not use one the The server MUST reject a RENEW that does not use one the
aforementioned algorithms, with the error NFS4ERR_ACCESS. aforementioned algorithms, with the error NFS4ERR_ACCESS.
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle
15.31.1. SYNOPSIS 15.31.1. SYNOPSIS
(sfh) -> (cfh) (sfh) -> (cfh)
15.31.2. ARGUMENT 15.31.2. ARGUMENT
/* SAVED_FH: */ /* SAVED_FH: */
void; void;
15.31.3. RESULT 15.31.3. RESULT
struct RESTOREFH4res { struct RESTOREFH4res {
/* CURRENT_FH: value of saved fh */ /* CURRENT_FH: value of saved fh */
nfsstat4 status; nfsstat4 status;
}; };
15.31.4. DESCRIPTION 15.31.4. DESCRIPTION
skipping to change at page 285, line 4 skipping to change at page 284, line 30
there is no saved filehandle then return the error NFS4ERR_RESTOREFH. there is no saved filehandle then return the error NFS4ERR_RESTOREFH.
15.31.5. IMPLEMENTATION 15.31.5. IMPLEMENTATION
Operations like OPEN and LOOKUP use the current filehandle to Operations like OPEN and LOOKUP use the current filehandle to
represent a directory and replace it with a new filehandle. Assuming represent a directory and replace it with a new filehandle. Assuming
the previous filehandle was saved with a SAVEFH operator, the the previous filehandle was saved with a SAVEFH operator, the
previous filehandle can be restored as the current filehandle. This previous filehandle can be restored as the current filehandle. This
is commonly used to obtain post-operation attributes for the is commonly used to obtain post-operation attributes for the
directory, e.g., directory, e.g.,
PUTFH (directory filehandle)
SAVEFH PUTFH (directory filehandle)
GETATTR attrbits (pre-op dir attrs) SAVEFH
CREATE optbits "foo" attrs GETATTR attrbits (pre-op dir attrs)
GETATTR attrbits (file attributes) CREATE optbits "foo" attrs
RESTOREFH GETATTR attrbits (file attributes)
GETATTR attrbits (post-op dir attrs) RESTOREFH
GETATTR attrbits (post-op dir attrs)
15.32. Operation 32: SAVEFH - Save Current Filehandle 15.32. Operation 32: SAVEFH - Save Current Filehandle
15.32.1. SYNOPSIS 15.32.1. SYNOPSIS
(cfh) -> (sfh) (cfh) -> (sfh)
15.32.2. ARGUMENT 15.32.2. ARGUMENT
/* CURRENT_FH: */ /* CURRENT_FH: */
void; void;
15.32.3. RESULT 15.32.3. RESULT
struct SAVEFH4res { struct SAVEFH4res {
/* SAVED_FH: value of current fh */ /* SAVED_FH: value of current fh */
nfsstat4 status; nfsstat4 status;
}; };
15.32.4. DESCRIPTION 15.32.4. DESCRIPTION
skipping to change at page 285, line 44 skipping to change at page 285, line 26
the current filehandle with the RESTOREFH operator. the current filehandle with the RESTOREFH operator.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
15.32.5. IMPLEMENTATION 15.32.5. IMPLEMENTATION
15.33. Operation 33: SECINFO - Obtain Available Security 15.33. Operation 33: SECINFO - Obtain Available Security
15.33.1. SYNOPSIS 15.33.1. SYNOPSIS
(cfh), name -> { secinfo } (cfh), name -> { secinfo }
15.33.2. ARGUMENT 15.33.2. ARGUMENT
struct SECINFO4args { struct SECINFO4args {
/* CURRENT_FH: directory */ /* CURRENT_FH: directory */
component4 name; component4 name;
}; };
15.33.3. RESULT 15.33.3. RESULT
skipping to change at page 287, line 15 skipping to change at page 287, line 7
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 server's mechanisms available, with an order corresponding to 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 [3]), or RPCSEC_GSS (as defined in [4]). AUTH_SYS (as defined in [4]), or RPCSEC_GSS (as defined in [5]).
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. For a return value of RPCSEC_GSS, a information is returned. For a return value of RPCSEC_GSS, a
security triple is returned that contains the mechanism object id (as security triple is returned that contains the mechanism object id (as
defined in [6]), the quality of protection (as defined in [6]) and defined in [6]), the quality of protection (as defined in [6]) and
the service type (as defined in [4]). It is possible for SECINFO to the service type (as defined in [5]). It is possible for SECINFO to
return multiple entries with flavor equal to RPCSEC_GSS with return multiple entries with flavor equal to RPCSEC_GSS with
different security triple values. different security triple values.
On success, the current filehandle retains its value. On success, the current filehandle retains its value.
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, the error NFS4ERR_INVAL will be returned.
15.33.5. IMPLEMENTATION 15.33.5. IMPLEMENTATION
skipping to change at page 288, line 47 skipping to change at page 288, line 39
the client has requested the rdattr_error attribute, the server will the client has requested the rdattr_error attribute, the server will
return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. return the NFS4ERR_WRONGSEC error in rdattr_error for the entry.
See Section 17 for a discussion on the recommendations for security See Section 17 for a discussion on the recommendations for security
flavor used by SECINFO. flavor used by SECINFO.
15.34. Operation 34: SETATTR - Set Attributes 15.34. Operation 34: SETATTR - Set Attributes
15.34.1. SYNOPSIS 15.34.1. SYNOPSIS
(cfh), stateid, attrmask, attr_vals -> attrsset (cfh), stateid, attrmask, attr_vals -> attrsset
15.34.2. ARGUMENT 15.34.2. ARGUMENT
struct SETATTR4args { struct SETATTR4args {
/* CURRENT_FH: target object */ /* CURRENT_FH: target object */
stateid4 stateid; stateid4 stateid;
fattr4 obj_attributes; fattr4 obj_attributes;
}; };
15.34.3. RESULT 15.34.3. RESULT
skipping to change at page 291, line 26 skipping to change at page 291, line 17
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 attribute bits not requested to be cases. That mask MUST NOT include attribute bits not requested to be
set by the client. If the attribute masks in the request and reply set by the client. If the attribute masks in the request and reply
are equal, the status field in the reply MUST be NFS4_OK. are equal, the status field in the reply MUST be NFS4_OK.
15.35. Operation 35: SETCLIENTID - Negotiate Client ID 15.35. Operation 35: SETCLIENTID - Negotiate Client ID
15.35.1. SYNOPSIS 15.35.1. SYNOPSIS
client, callback, callback_ident -> clientid, setclientid_confirm client, callback, callback_ident -> clientid, setclientid_confirm
15.35.2. ARGUMENT 15.35.2. ARGUMENT
struct SETCLIENTID4args { struct SETCLIENTID4args {
nfs_client_id4 client; nfs_client_id4 client;
cb_client4 callback; cb_client4 callback;
uint32_t callback_ident; uint32_t callback_ident;
}; };
15.35.3. RESULT 15.35.3. RESULT
skipping to change at page 295, line 26 skipping to change at page 294, line 49
delegation) state for x. delegation) state for x.
The server generates the clientid and setclientid_confirm values and The server generates the clientid and setclientid_confirm values and
must take care to ensure that these values are extremely unlikely to must take care to ensure that these values are extremely unlikely to
ever be regenerated. ever be regenerated.
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID
15.36.1. SYNOPSIS 15.36.1. SYNOPSIS
clientid, verifier -> - clientid, verifier -> -
15.36.2. ARGUMENT 15.36.2. ARGUMENT
struct SETCLIENTID_CONFIRM4args { struct SETCLIENTID_CONFIRM4args {
clientid4 clientid; clientid4 clientid;
verifier4 setclientid_confirm; verifier4 setclientid_confirm;
}; };
15.36.3. RESULT 15.36.3. RESULT
skipping to change at page 298, line 50 skipping to change at page 298, line 22
state does not include existing delegations, the server MUST allow state does not include existing delegations, the server MUST allow
the client a period of time no less than the value of lease_time the client a period of time no less than the value of lease_time
attribute, to reclaim, (via the CLAIM_DELEGATE_PREV claim type of the attribute, to reclaim, (via the CLAIM_DELEGATE_PREV claim type of the
OPEN operation) its delegations before removing unreclaimed OPEN operation) its delegations before removing unreclaimed
delegations. delegations.
15.37. Operation 37: VERIFY - Verify Same Attributes 15.37. Operation 37: VERIFY - Verify Same Attributes
15.37.1. SYNOPSIS 15.37.1. SYNOPSIS
(cfh), fattr -> - (cfh), fattr -> -
15.37.2. ARGUMENT 15.37.2. ARGUMENT
struct VERIFY4args { struct VERIFY4args {
/* CURRENT_FH: object */ /* CURRENT_FH: object */
fattr4 obj_attributes; fattr4 obj_attributes;
}; };
15.37.3. RESULT 15.37.3. RESULT
skipping to change at page 299, line 33 skipping to change at page 299, line 6
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.
15.37.5. IMPLEMENTATION 15.37.5. IMPLEMENTATION
One possible use of the VERIFY operation is the following compound One possible use of the VERIFY operation is the following compound
sequence. With this the client is attempting to verify that the file sequence. With this the client is attempting to verify that the file
being removed will match what the client expects to be removed. This being removed will match what the client expects to be removed. This
sequence can help prevent the unintended deletion of a file. sequence 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 sequence 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 operation and the server does not support that attribute for the
filesystem object, the error NFS4ERR_ATTRNOTSUPP is returned to the filesystem 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 write-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.
15.38. Operation 38: WRITE - Write to File 15.38. Operation 38: WRITE - Write to File
15.38.1. SYNOPSIS 15.38.1. SYNOPSIS
(cfh), stateid, offset, stable, data -> count, committed, writeverf (cfh), stateid, offset, stable, data -> count, committed, writeverf
15.38.2. ARGUMENT 15.38.2. ARGUMENT
enum stable_how4 { enum stable_how4 {
UNSTABLE4 = 0, UNSTABLE4 = 0,
DATA_SYNC4 = 1, DATA_SYNC4 = 1,
FILE_SYNC4 = 2 FILE_SYNC4 = 2
}; };
struct WRITE4args { struct WRITE4args {
skipping to change at page 304, line 21 skipping to change at page 303, line 43
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.
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner State 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner State
15.39.1. SYNOPSIS 15.39.1. SYNOPSIS
lock-owner -> () lock-owner -> ()
15.39.2. ARGUMENT 15.39.2. ARGUMENT
struct RELEASE_LOCKOWNER4args { struct RELEASE_LOCKOWNER4args {
lock_owner4 lock_owner; lock_owner4 lock_owner;
}; };
15.39.3. RESULT 15.39.3. RESULT
struct RELEASE_LOCKOWNER4res { struct RELEASE_LOCKOWNER4res {
nfsstat4 status; nfsstat4 status;
}; };
15.39.4. DESCRIPTION 15.39.4. DESCRIPTION
This operation is used to notify the server that the lock_owner is no This operation is used to notify the server that the lock_owner is no
longer in use by the client. This allows the server to release longer in use by the client and that future client requests will not
cached state related to the specified lock_owner. If file locks, reference this lock_owner. This allows the server to release cached
associated with the lock_owner, are held at the server, the error state related to the specified lock_owner. If file locks, associated
with the lock_owner, are held at the server, the error
NFS4ERR_LOCKS_HELD will be returned and no further action will be NFS4ERR_LOCKS_HELD will be returned and no further action will be
taken. taken.
15.39.5. IMPLEMENTATION 15.39.5. IMPLEMENTATION
The client may choose to use this operation to ease the amount of The client may choose to use this operation to ease the amount of
server state that is held. Depending on behavior of applications at server state that is held. Information that can be released when a
the client, it may be important for the client to use this operation RELEASE_LOCKOWNER is done includes the specified lock-owner string,
since the server has certain obligations with respect to holding a the seqid associated with the lock-owner, any saved reply for the
reference to a lock_owner as long as the associated file is open. lock-owner, and any lock stateids associated with that lock-owner.
Depending on the behavior of applications at the client, it may be
important for the client to use this operation since the server has
certain obligations with respect to holding a reference to lock-
owner-associated state as long as an associated file is open.
Therefore, if the client knows for certain that the lock_owner will Therefore, if the client knows for certain that the lock_owner will
no longer be used under the context of the associated open_owner4, it no longer be used, either to reference existing lock stateids
should use RELEASE_LOCKOWNER. associated with the lock-owner to create new ones, it should use
RELEASE_LOCKOWNER.
15.40. Operation 10044: ILLEGAL - Illegal operation 15.40. Operation 10044: ILLEGAL - Illegal operation
15.40.1. SYNOPSIS 15.40.1. SYNOPSIS
<null> -> () <null> -> ()
15.40.2. ARGUMENT 15.40.2. ARGUMENT
void; void;
15.40.3. RESULT 15.40.3. RESULT
struct ILLEGAL4res { struct ILLEGAL4res {
nfsstat4 status; nfsstat4 status;
}; };
15.40.4. DESCRIPTION 15.40.4. DESCRIPTION
This operation is a placeholder for encoding a result to handle the This operation is a placeholder for encoding a result to handle the
skipping to change at page 306, line 9 skipping to change at page 305, line 40
The procedures used for callbacks are defined in the following The procedures used for callbacks are defined in the following
sections. In the interest of clarity, the terms "client" and sections. In the interest of clarity, the terms "client" and
"server" refer to NFS clients and servers, despite the fact that for "server" refer to NFS clients and servers, despite the fact that for
an individual callback RPC, the sense of these terms would be an individual callback RPC, the sense of these terms would be
precisely the opposite. precisely the opposite.
16.1. Procedure 0: CB_NULL - No Operation 16.1. Procedure 0: CB_NULL - No Operation
16.1.1. SYNOPSIS 16.1.1. SYNOPSIS
<null> <null>
16.1.2. ARGUMENT 16.1.2. ARGUMENT
void; void;
16.1.3. RESULT 16.1.3. RESULT
void; void;
16.1.4. DESCRIPTION 16.1.4. DESCRIPTION
Standard NULL procedure. Void argument, void response. Even though Standard NULL procedure. Void argument, void response. Even though
there is no direct functionality associated with this procedure, the there is no direct functionality associated with this procedure, the
server will use CB_NULL to confirm the existence of a path for RPCs server will use CB_NULL to confirm the existence of a path for RPCs
from server to client. from server to client.
16.2. Procedure 1: CB_COMPOUND - Compound Operations 16.2. Procedure 1: CB_COMPOUND - Compound Operations
16.2.1. SYNOPSIS 16.2.1. SYNOPSIS
compoundargs -> compoundres compoundargs -> compoundres
16.2.2. ARGUMENT 16.2.2. ARGUMENT
enum nfs_cb_opnum4 { enum nfs_cb_opnum4 {
OP_CB_GETATTR = 3, OP_CB_GETATTR = 3,
OP_CB_RECALL = 4, OP_CB_RECALL = 4,
OP_CB_ILLEGAL = 10044 OP_CB_ILLEGAL = 10044
}; };
union nfs_cb_argop4 switch (unsigned argop) { union nfs_cb_argop4 switch (unsigned argop) {
skipping to change at page 308, line 23 skipping to change at page 308, line 9
operations in turn. If an operation is executed by the client and operations in turn. If an operation is executed by the client and
the status of that operation is NFS4_OK, then the next operation in the status of that operation is NFS4_OK, then the next operation in
the CB_COMPOUND procedure is executed. The client continues this the CB_COMPOUND procedure is executed. The client continues this
process until there are no more operations to be executed or one of process until there are no more operations to be executed or one of
the operations has a status value other than NFS4_OK. the operations has a status value other than NFS4_OK.
16.2.6. Operation 3: CB_GETATTR - Get Attributes 16.2.6. Operation 3: CB_GETATTR - Get Attributes
16.2.6.1. SYNOPSIS 16.2.6.1. SYNOPSIS
fh, attr_request -> attrmask, attr_vals fh, attr_request -> attrmask, attr_vals
16.2.6.2. ARGUMENT 16.2.6.2. ARGUMENT
struct CB_GETATTR4args { struct CB_GETATTR4args {
nfs_fh4 fh; nfs_fh4 fh;
bitmap4 attr_request; bitmap4 attr_request;
}; };
16.2.6.3. RESULT 16.2.6.3. RESULT
skipping to change at page 309, line 21 skipping to change at page 309, line 9
16.2.6.5. IMPLEMENTATION 16.2.6.5. IMPLEMENTATION
The client returns attrmask bits and the associated attribute values The client returns attrmask bits and the associated attribute values
only for the change attribute, and attributes that it may change only for the change attribute, and attributes that it may change
(time_modify, and size). (time_modify, and size).
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation
16.2.7.1. SYNOPSIS 16.2.7.1. SYNOPSIS
stateid, truncate, fh -> () stateid, truncate, fh -> ()
16.2.7.2. ARGUMENT 16.2.7.2. ARGUMENT
struct CB_RECALL4args { struct CB_RECALL4args {
stateid4 stateid; stateid4 stateid;
bool truncate; bool truncate;
nfs_fh4 fh; nfs_fh4 fh;
}; };
16.2.7.3. RESULT 16.2.7.3. RESULT
skipping to change at page 310, line 20 skipping to change at page 310, line 9
The client should reply to the callback immediately. Replying does The client should reply to the callback immediately. Replying does
not complete the recall except when an error was returned. The not complete the recall except when an error was returned. The
recall is not complete until the delegation is returned using a recall is not complete until the delegation is returned using a
DELEGRETURN. DELEGRETURN.
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback Operation 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback Operation
16.2.8.1. SYNOPSIS 16.2.8.1. SYNOPSIS
<null> -> () <null> -> ()
16.2.8.2. ARGUMENT 16.2.8.2. ARGUMENT
void; void;
16.2.8.3. RESULT 16.2.8.3. RESULT
/* /*
* CB_ILLEGAL: Response for illegal operation numbers * CB_ILLEGAL: Response for illegal operation numbers
*/ */
struct CB_ILLEGAL4res { struct CB_ILLEGAL4res {
nfsstat4 status; nfsstat4 status;
}; };
skipping to change at page 312, line 23 skipping to change at page 312, line 13
server controlled by the attacker. server controlled by the attacker.
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are
responsible for the release of client state, it is imperative that responsible for the release of client state, it is imperative that
the principal used for these operations is checked against and match the principal used for these operations is checked against and match
the previous use of these operations. See Section 9.1.1 for further the previous use of these operations. See Section 9.1.1 for further
discussion. discussion.
18. IANA Considerations 18. IANA Considerations
This section uses terms that are defined in [41]. This section uses terms that are defined in [39].
18.1. Named Attribute Definitions 18.1. Named Attribute Definitions
IANA will create a registry called the "NFSv4 Named Attribute IANA will create a registry called the "NFSv4 Named Attribute
Definitions Registry". Definitions Registry".
The NFSv4 protocol supports the association of a file with zero or The NFSv4 protocol supports the association of a file with zero or
more named attributes. The name space identifiers for these more named attributes. The name space identifiers for these
attributes are defined as string names. The protocol does not define attributes are defined as string names. The protocol does not define
the specific assignment of the name space for these file attributes. the specific assignment of the name space for these file attributes.
skipping to change at page 312, line 46 skipping to change at page 312, line 36
attributes as needed, they are encouraged to register the attributes attributes as needed, they are encouraged to register the attributes
with IANA. with IANA.
Such registered named attributes are presumed to apply to all minor Such registered named attributes are presumed to apply to all minor
versions of NFSv4, including those defined subsequently to the versions of NFSv4, including those defined subsequently to the
registration. Where the named attribute is intended to be limited registration. Where the named attribute is intended to be limited
with regard to the minor versions for which they are not be used, the with regard to the minor versions for which they are not be used, the
assignment in registry will clearly state the applicable limits. assignment in registry will clearly state the applicable limits.
All assignments to the registry are made on a First Come First Served All assignments to the registry are made on a First Come First Served
basis, per section 4.1 of [41]. The policy for each assignment is basis, per section 4.1 of [39]. The policy for each assignment is
Specification Required, per section 4.1 of [41]. Specification Required, per section 4.1 of [39].
Under the NFSv4 specification, the name of a named attribute can in Under the NFSv4 specification, the name of a named attribute can in
theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 theory be up to 2^32 - 1 bytes in length, but in practice NFSv4
clients and servers will be unable to a handle string that long. clients and servers will be unable to a handle string that long.
IANA should reject any assignment request with a named attribute that IANA should reject any assignment request with a named attribute that
exceeds 128 UTF-8 characters. To give IESG the flexibility to set up exceeds 128 UTF-8 characters. To give IESG the flexibility to set up
bases of assignment of Experimental Use and Standards Action, the bases of assignment of Experimental Use and Standards Action, the
prefixes of "EXPE" and "STDS" are Reserved. The zero length named prefixes of "EXPE" and "STDS" are Reserved. The zero length named
attribute name is Reserved. attribute name is Reserved.
skipping to change at page 314, line 31 skipping to change at page 314, line 19
"tcp6": TCP over IP version 6 "tcp6": TCP over IP version 6
"udp6": UDP over IP version 6 "udp6": UDP over IP version 6
Note: the '"' marks are used for delimiting the strings for this Note: the '"' marks are used for delimiting the strings for this
document and are not part of the Network Identifier string. document and are not part of the Network Identifier string.
For the "tcp" and "udp" Network Identifiers the Universal Address or For the "tcp" and "udp" Network Identifiers the Universal Address or
r_addr (for IPv4) is a US-ASCII string and is of the form: r_addr (for IPv4) is a US-ASCII string and is of the form:
h1.h2.h3.h4.p1.p2 h1.h2.h3.h4.p1.p2
The prefix, "h1.h2.h3.h4", is the standard textual form for The prefix, "h1.h2.h3.h4", is the standard textual form for
representing an IPv4 address, which is always four octets long. representing an IPv4 address, which is always four octets long.
Assuming big-endian ordering, h1, h2, h3, and h4, are respectively, Assuming big-endian ordering, h1, h2, h3, and h4, are respectively,
the first through fourth octets each converted to ASCII-decimal. the first through fourth octets each converted to ASCII-decimal.
Assuming big-endian ordering, p1 and p2 are, respectively, the first Assuming big-endian ordering, p1 and p2 are, respectively, the first
and second octets each converted to ASCII-decimal. For example, if a and second octets each converted to ASCII-decimal. For example, if a
host, in big-endian order, has an address of 0x0A010307 and there is host, in big-endian order, has an address of 0x0A010307 and there is
a service listening on, in big endian order, port 0x020F (decimal a service listening on, in big endian order, port 0x020F (decimal
527), then complete universal address is "10.1.3.7.2.15". 527), then complete universal address is "10.1.3.7.2.15".
For the "tcp6" and "udp6" Network Identifiers the Universal Address For the "tcp6" and "udp6" Network Identifiers the Universal Address
or r_addr (for IPv6) is a US-ASCII string and is of the form: or r_addr (for IPv6) is a US-ASCII string and is of the form:
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
The suffix "p1.p2" is the service port, and is computed the same way The suffix "p1.p2" is the service port, and is computed the same way
as with universal addresses for "tcp" and "udp". The prefix, "x1:x2: as with universal addresses for "tcp" and "udp". The prefix, "x1:x2:
x3:x4:x5:x6:x7:x8", is the standard textual form for representing an x3:x4:x5:x6:x7:x8", is the standard textual form for representing an
IPv6 address as defined in Section 2.2 of [18]. Additionally, the IPv6 address as defined in Section 2.2 of [17]. Additionally, the
two alternative forms specified in Section 2.2 of [18] are also two alternative forms specified in Section 2.2 of [17] are also
acceptable. acceptable.
18.2.1. Initial Registry 18.2.1. Initial Registry
There is no initial registry. There is no initial registry.
18.2.2. Updating Registrations 18.2.2. Updating Registrations
The registrant is always permitted to update the point of contact The registrant is always permitted to update the point of contact
field. To make any other change will require Expert Review or IESG field. To make any other change will require Expert Review or IESG
skipping to change at page 315, line 28 skipping to change at page 315, line 16
19.1. Normative References 19.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
[2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description", [2] Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR Description",
draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress), draft-ietf-nfsv4-rfc3530bis-dot-x-02 (work in progress),
Feb 2011. Feb 2011.
[3] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification [3] Klensin, J., "Internationalized Domain Names in Applications
(IDNA): Protocol", draft-ietf-idnabis-protocol-18 (work in
progress), January 2010.
[4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification
Version 2", RFC 5531, May 2009. Version 2", RFC 5531, May 2009.
[4] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [5] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[5] Eisler, M., "LIPKEY - A Low Infrastructure Public Key Mechanism
Using SPKM", RFC 2847, June 2000.
[6] Linn, J., "Generic Security Service Application Program [6] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[7] International Organization for Standardization, "Information [7] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS) Technology - Universal Multiple-octet coded Character Set (UCS)
- Part 1: Architecture and Basic Multilingual Plane", - Part 1: Architecture and Basic Multilingual Plane",
ISO Standard 10646-1, May 1993. ISO Standard 10646-1, May 1993.
[8] Alvestrand, H., "IETF Policy on Character Sets and Languages", [8] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998. BCP 18, RFC 2277, January 1998.
[9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002. Strings ("stringprep")", RFC 3454, December 2002.
[10] Klensin, J., "Internationalized Domain Names in Applications
(IDNA): Protocol", draft-ietf-idnabis-protocol-18 (work in
progress), January 2010.
19.2. Informative References 19.2. Informative References
[11] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [10] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M., and D. Noveck, "Network File System (NFS) C., Eisler, M., and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 3530, April 2003. version 4 Protocol", RFC 3530, April 2003.
[12] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, [11] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M., and D. Noveck, "Network File System (NFS) C., Eisler, M., and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 3010, December 2000. version 4 Protocol", RFC 3010, December 2000.
[13] Nowicki, B., "NFS: Network File System Protocol specification", [12] Nowicki, B., "NFS: Network File System Protocol specification",
RFC 1094, March 1989. RFC 1094, March 1989.
[14] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 [13] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3
Protocol Specification", RFC 1813, June 1995. Protocol Specification", RFC 1813, June 1995.
[15] Eisler, M., "XDR: External Data Representation Standard", [14] Eisler, M., "XDR: External Data Representation Standard",
RFC 4506, May 2006. RFC 4506, May 2006.
[16] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, [15] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996. June 1996.
[17] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [16] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995. RFC 1833, August 1995.
[18] Hinden, R. and S. Deering, "IP Version 6 Addressing [17] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[19] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- [18] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
line Database", RFC 3232, January 2002. line Database", RFC 3232, January 2002.
[20] Floyd, S. and V. Jacobson, "The Synchronization of Periodic [19] Floyd, S. and V. Jacobson, "The Synchronization of Periodic
Routing Messages", IEEE/ACM Transactions on Networking 2(2), Routing Messages", IEEE/ACM Transactions on Networking 2(2),
pp. 122-136, April 1994. pp. 122-136, April 1994.
[21] Eisler, M., "NFS Version 2 and Version 3 Security Issues and [20] Eisler, M., "NFS Version 2 and Version 3 Security Issues and
the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999. RFC 2623, June 1999.
[22] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [21] Callaghan, B., "WebNFS Client Specification", RFC 2054,
RFC 2025, October 1996.
[23] Callaghan, B., "WebNFS Client Specification", RFC 2054,
October 1996. October 1996.
[24] Callaghan, B., "WebNFS Server Specification", RFC 2055, [22] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. October 1996.
[25] IESG, "IESG Processing of RFC Errata for the IETF Stream", [23] IESG, "IESG Processing of RFC Errata for the IETF Stream",
July 2008. July 2008.
[26] The Open Group, "Section 'read()' of System Interfaces of The [24] The Open Group, "Section 'read()' of System Interfaces of The
Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004
Edition", 2004. Edition", 2004.
[27] The Open Group, "Section 'readdir()' of System Interfaces of [25] The Open Group, "Section 'readdir()' of System Interfaces of
The Open Group Base Specifications Issue 6, IEEE Std 1003.1, The Open Group Base Specifications Issue 6, IEEE Std 1003.1,
2004 Edition", 2004. 2004 Edition", 2004.
[28] The Open Group, "Section 'write()' of System Interfaces of The [26] The Open Group, "Section 'write()' of System Interfaces of The
Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004
Edition", 2004. Edition", 2004.
[29] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, [27] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624,
June 1999. June 1999.
[30] Simonsen, K., "Character Mnemonics and Character Sets", [28] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, June 1992. RFC 1345, June 1992.
[31] Shepler, S., Eisler, M., and D. Noveck, "Network File System [29] Shepler, S., Eisler, M., and D. Noveck, "Network File System
(NFS) Version 4 Minor Version 1 Protocol", RFC 5661, (NFS) Version 4 Minor Version 1 Protocol", RFC 5661,
January 2010. January 2010.
[32] The Open Group, "Protocols for Interworking: XNFS, Version 3W, [30] The Open Group, "Protocols for Interworking: XNFS, Version 3W,
ISBN 1-85912-184-5", February 1998. ISBN 1-85912-184-5", February 1998.
[33] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [31] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[34] Juszczak, C., "Improving the Performance and Correctness of an [32] Juszczak, C., "Improving the Performance and Correctness of an
NFS Server", USENIX Conference Proceedings , June 1990. NFS Server", USENIX Conference Proceedings , June 1990.
[35] The Open Group, "Section 'fcntl()' of System Interfaces of The [33] The Open Group, "Section 'fcntl()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[36] The Open Group, "Section 'fsync()' of System Interfaces of The [34] The Open Group, "Section 'fsync()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[37] The Open Group, "Section 'getpwnam()' of System Interfaces of [35] The Open Group, "Section 'getpwnam()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std 1003.1, The Open Group Base Specifications Issue 6 IEEE Std 1003.1,
2004 Edition, HTML Version (www.opengroup.org), ISBN 2004 Edition, HTML Version (www.opengroup.org), ISBN
1931624232", 2004. 1931624232", 2004.
[38] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [36] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[39] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation [37] Chiu, A., Eisler, M., and B. Callaghan, "Security Negotiation
for WebNFS", RFC 2755, January 2000. for WebNFS", RFC 2755, January 2000.
[40] The Open Group, "Section 'unlink()' of System Interfaces of The [38] The Open Group, "Section 'unlink()' of System Interfaces of The
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004
Edition, HTML Version (www.opengroup.org), ISBN 1931624232", Edition, HTML Version (www.opengroup.org), ISBN 1931624232",
2004. 2004.
[41] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [39] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Appendix A. Acknowledgments Appendix A. Acknowledgments
A bis is certainly built on the shoulders of the first attempt. A bis is certainly built on the shoulders of the first attempt.
Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow,
Carl Beame, Mike Eisler, and David Noveck are responsible for a great Carl Beame, Mike Eisler, and David Noveck are responsible for a great
deal of the effort in this work. deal of the effort in this work.
Rob Thurlow clarified how a client should contact a new server if a Rob Thurlow clarified how a client should contact a new server if a
skipping to change at page 319, line 5 skipping to change at page 318, line 35
James Lentini graciously read the rewrite of Section 7 and his James Lentini graciously read the rewrite of Section 7 and his
comments were vital in improving the quality of that effort. comments were vital in improving the quality of that effort.
Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond
Myklebust were faithful attendants of the biweekly triage meeting and Myklebust were faithful attendants of the biweekly triage meeting and
accepted many an action item. accepted many an action item.
Bruce Fields was a good sounding board for both the Third Edge Bruce Fields was a good sounding board for both the Third Edge
Condition and Courtsey Locks in general. Condition and Courtsey Locks in general.
Marcel Telka was a champion of straightening out the difference
between a lock-owner and an open-owner. He has also been diligent in
reviewing the final document.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the replace all occurences of RFCNFSv4XDR with RFCxxxx where xxxx is the
RFC number of this document] RFC number assigned to the XDR document.]
[RFC Editor: Please note that there is also a reference entry that
needs to be modified for the companion document.]
Authors' Addresses Authors' Addresses
Thomas Haynes (editor) Thomas Haynes (editor)
NetApp NetApp
9110 E 66th St 9110 E 66th St
Tulsa, OK 74133 Tulsa, OK 74133
USA USA
Phone: +1 918 307 1415 Phone: +1 918 307 1415
Email: thomas@netapp.com Email: thomas@netapp.com
URI: http://www.tulsalabs.com URI: http://www.tulsalabs.com
David Noveck (editor) David Noveck (editor)
EMC Corporation EMC Corporation
32 Coslin Drive 228 South Street
Southborough, MA 01772 Hopkinton, MA 01748
US US
Phone: +1 508 305 8404 Phone: +1 508 249 5748
Email: novecd@emc.com Email: david.noveck@emc.com
 End of changes. 257 change blocks. 
763 lines changed or deleted 784 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/