? 2008-03-22-ch14-15.html ? 2008-03-23-ch16.html ? 2008-03-31-ch16.html ? 2008-04-05-ch18_thru_link.html ? 2008-04-06-ch18_thru_link.html ? 2008-04-07-ch18_thru_link.html ? 2008-04-08-ch18_thru_link.html ? 2008-04-08-retention.html ? 2008-04-09-ch-18-lock-.html ? 2008-04-09-retention.html ? 2008-04-10-ch-18-lock-open.html ? 2008-04-11-ch-18-openattr-remove.html ? 2008-04-11-ch-18-rename-.html ? 2008-04-12-ch-18-rename-write.html ? 2008-04-17-ch-18-rename-write.html ? 2008-04-17-ch-18-rename-write.txt ? 2008-04-18-ch-18-backchannel_ctl.html ? CHANGES ? Merged.txt ? Merged17.txt ? MikeE-orig.txt ? MikeE.txt ? MikeE2-comments.txt ? MikeE2.txt ? MikeE3.txt ? R.txt ? RobertG.txt ? autogen ? c ? cache.patch ? ch3.html ? ch5.htm ? check_xml ? d ? d.txt ? dd ? dev2diff.txt ? devdiff.txt ? diff ? diff.txt ? diffs.txt ? draft-10 ? draft-10.tar.gz ? draft-11 ? draft-11.tar.gz ? draft-12 ? draft-12.tar.gz ? draft-14 ? draft-14.tar ? draft-16 ? draft-16.tar ? draft-17 ? draft-17.tar ? draft-18 ? draft-18.tar.gz ? draft-19 ? draft-19.tar.gz ? draft-20 ? draft-20.tar.gz ? draft-21 ? draft-21.tar.gz ? draft-22 ? draft-22.tar.gz ? draft-ch-18-pre-backchannel_ctl.txt ? draft-ietf-nfsv4-minorversion1-11-ln.txt ? draft-ietf-nfsv4-minorversion1-11.html ? draft-ietf-nfsv4-minorversion1-11.txt ? draft-ietf-nfsv4-minorversion1-12.html ? draft-ietf-nfsv4-minorversion1-13.html ? draft-ietf-nfsv4-minorversion1-13.txt ? draft-ietf-nfsv4-minorversion1-14.html ? draft-ietf-nfsv4-minorversion1-14.txt ? draft-ietf-nfsv4-minorversion1-15.html ? draft-ietf-nfsv4-minorversion1-17.html ? draft-ietf-nfsv4-minorversion1-18.html ? draft-ietf-nfsv4-minorversion1-18.txt ? draft-ietf-nfsv4-minorversion1-18.xml ? draft-ietf-nfsv4-minorversion1-19.html ? draft-ietf-nfsv4-minorversion1-19.txt ? draft-ietf-nfsv4-minorversion1-19.xml ? draft-ietf-nfsv4-minorversion1-20.html ? draft-ietf-nfsv4-minorversion1-20.txt ? draft-ietf-nfsv4-minorversion1-20.xml ? draft-ietf-nfsv4-minorversion1-21.html ? draft-ietf-nfsv4-minorversion1-21.txt ? draft-ietf-nfsv4-minorversion1-21.xml ? draft-ietf-nfsv4-minorversion1-22.html ? draft-ietf-nfsv4-minorversion1-22.txt ? draft-ietf-nfsv4-minorversion1-22.xml ? draft-post-byte-range.txt ? draft-post-ch-11.txt ? draft-post-ch-14-15.txt ? draft-pre-ch-11.txt ? draft-pre-ch-14.txt ? draft-pre-ch-16.txt ? draft-pre-ch-17-lock.txt ? draft-pre-ch-17.txt ? draft-pre-ch-18-lock.txt ? draft-pre-ch-18-openattr.txt ? draft-pre-ch-18-rename.txt ? draft-pre-ch-7.txt ? draft-pre-ch-9.txt ? draft-pre-ch5.txt ? draft-pre-record-byte-range.txt ? draft-pre-retention.txt ? draft-tmp.xml ? fscaps ? g ? gdldiff.txt ? gdldiff2.txt ? gdldiff3.txt ? issues ? layout2diff.txt ? layout3diff.txt ? layout4diff.txt ? layoutdiff.txt ? m ? m.sh.save ? mcclure.dreamhost.com ? nfsv41_front_autogen.xml ? nfsv41_middle_errortoop_autogen.xml ? nfsv41_rfc_start_autogen.xml ? notifydiff.txt ? rfcdiff-byte-range.html ? rfcdiff-ch11.html ? rfcdiff-ch14-15.html ? rfcdiff-ch16.html ? rfcdiff-ch7-8.html ? rfcdiff-ch9-10.html ? s ? save.xml ? secneg ? t.txt ? t2.txt ? t3.txt ? testx.d ? tt ? dotx-id.d/DIFF ? dotx-id.d/dotx_autogen.xml ? dotx-id.d/dotx_front_autogen.xml ? dotx-id.d/dotx_rfc_start_autogen.xml ? dotx-id.d/draft-ietf-nfsv4-minorversion1-dot-x-01.txt ? dotx-id.d/draft-ietf-nfsv4-minorversion1-dot-x-01.xml ? dotx-id.d/draft-ietf-nfsv4-minorversion1-dot-x-02.txt ? dotx-id.d/draft-ietf-nfsv4-minorversion1-dot-x-02.xml ? dotx-id.d/draft-ietf-nfsv4-minorversion1-dot-x-03.xml ? dotx-id.d/draft-ietf-nfsv4-minorversion1-dot-x-04.txt ? dotx-id.d/draft-ietf-nfsv4-minorversion1-dot-x-04.xml ? dotx-id.d/t ? dotx-id.d/tmp.filelist ? dotx-id.d/tmp.sh ? dotx-id.d/tmp.txt ? dotx-id.d/tmp.x ? dotx.d/.cb_notify_args.x ? dotx.d/.nfsv41.x.swp ? dotx.d/DIFF ? dotx.d/arg ? dotx.d/back_ops.x ? dotx.d/basic_types.x ? dotx.d/co ? dotx.d/const_access_deny.x ? dotx.d/const_aceflag4.x ? dotx.d/const_acemask4.x ? dotx.d/const_acetype4.x ? dotx.d/const_aclflag4.x ? dotx.d/const_aclsupport4.x ? dotx.d/const_mode4.x ? dotx.d/const_sizes.x ? dotx.d/d ? dotx.d/fore_ops.x ? dotx.d/hand_edit_warning.x ? dotx.d/nfsv41.x ? dotx.d/open_args_gen.x ? dotx.d/opendiff.txt ? dotx.d/opnum ? dotx.d/t ? dotx.d/tmp.filelist ? dotx.d/type_CB_COMPOUND4args.x ? dotx.d/type_CB_COMPOUND4res.x ? dotx.d/type_COMPOUND4args.x ? dotx.d/type_COMPOUND4res.x ? dotx.d/type_aceflag4.x ? dotx.d/type_acemask4.x ? dotx.d/type_acetype4.x ? dotx.d/type_change_info4.x ? dotx.d/type_chg_policy4.x ? dotx.d/type_client_owner4.x ? dotx.d/type_device_addr4.x ? dotx.d/type_deviceid4.x ? dotx.d/type_fattr4.x ? dotx.d/type_fs4_status.x ? dotx.d/type_fs_charset_cap4.x ? dotx.d/type_fs_location4.x ? dotx.d/type_fs_locations4.x ? dotx.d/type_fsid4.x ? dotx.d/type_layout4.x ? dotx.d/type_layout_content4.x ? dotx.d/type_layouthint4.x ? dotx.d/type_layoutiomode4.x ? dotx.d/type_layoutreturn4.x ? dotx.d/type_layouttype4.x ? dotx.d/type_layoutupdate4.x ? dotx.d/type_mdsthreshold4.x ? dotx.d/type_netaddr4.x ? dotx.d/type_nfl_util4.x ? dotx.d/type_nfs_argop4.x ? dotx.d/type_nfs_cb_argop4.x ? dotx.d/type_nfs_cb_opnum4.x ? dotx.d/type_nfs_cb_resop4.x ? dotx.d/type_nfs_impl_id4.x ? dotx.d/type_nfs_opnum4.x ? dotx.d/type_nfs_resop4.x ? dotx.d/type_nfsace4.x ? dotx.d/type_nfstime4.x ? dotx.d/type_nfsv4_1_file_layout4.x ? dotx.d/type_nfsv4_1_file_layout_ds_addr4.x ? dotx.d/type_nfsv4_1_file_layouthint4.x ? dotx.d/type_open_to_lock_owner4.x ? dotx.d/type_retention_get4.x ? dotx.d/type_retention_set4.x ? dotx.d/type_server_owner4.x ? dotx.d/type_settime4.x ? dotx.d/type_specdata4.x ? dotx.d/type_ssv_mic_plain_tkn4.x ? dotx.d/type_ssv_mic_tkn4.x ? dotx.d/type_ssv_seal_cipher_tkn4.x ? dotx.d/type_ssv_seal_plain_tkn4.x ? dotx.d/type_ssv_subkey4.x ? dotx.d/type_state_owner4.x ? dotx.d/type_stateid4.x ? dotx.d/type_threshold_item4.x ? dotx.d/type_time_how4.x ? dotx.d/z ? rpcsec_gss_v2/d.html ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-00.html ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-00.txt ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-01.html ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-01.txt ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-01.xml ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-02.html ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-02.txt ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-02.xml ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-03.html ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-03.txt ? rpcsec_gss_v2/draft-ietf-nfsv4-rpcsec-gss-v2-03.xml ? rpcsec_gss_v2/rpcsec_gss_v2_front_autogen.xml ? rpcsec_gss_v2/rpcsec_gss_v2_rfc_start_autogen.xml ? rpcsec_gss_v2/tmp.txt Index: nfsv41_back_references.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_back_references.xml,v retrieving revision 1.17 diff -u -r1.17 nfsv41_back_references.xml --- nfsv41_back_references.xml 31 Jan 2008 01:30:48 -0000 1.17 +++ nfsv41_back_references.xml 18 Apr 2008 16:55:01 -0000 @@ -1228,4 +1228,21 @@ + + + The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition + + + The Open Group + + + + + + The description of the access() function states: "If the process has appropriate privileges, an implementation may indicate success for X_OK even if none of the execute file permission bits are set." + + + + + Index: nfsv41_middle_core_infrastructure.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_core_infrastructure.xml,v retrieving revision 1.89 diff -u -r1.89 nfsv41_middle_core_infrastructure.xml --- nfsv41_middle_core_infrastructure.xml 31 Mar 2008 23:18:57 -0000 1.89 +++ nfsv41_middle_core_infrastructure.xml 18 Apr 2008 16:55:02 -0000 @@ -774,16 +774,30 @@
This section explains of the mechanics of NFSv4.1 security negotiation. + + +
+ + + The term "put filehandle operation" refers to - PUTROOTFH, PUTPUBFH, PUTFH, and RESTOREFH. + PUTROOTFH, PUTPUBFH, PUTFH, and RESTOREFH. Each of the subsections + herein describes how the server handles a subseries of operations + that starts with a put filehandle operation.
- The client is saving a filehandle for a future RESTOREFH. The - server MUST NOT return NFS4ERR_WRONGSEC to either the put filehandle - operation or SAVEFH. + The client is saving a filehandle for a future + RESTOREFH, LINK, or RENAME. SAVEFH MUST NOT + return NFS4ERR_WRONGSEC. To determine whether the put + filehandle operation returns NFS4ERR_WRONGSEC or not, + the server implementation pretends SAVEFH is not in + the series of operations and examines which of the + situations described in the other subsections of apply. +
+ title="Put Filehandle Operation + LOOKUP (or OPEN of an Existing Name)"> This situation also applies to a put filehandle operation followed - by a LOOKUP or an OPEN operation that specifies a component name. + by a LOOKUP or an OPEN operation that specifies an existing component name. In this situation, the client is potentially crossing @@ -841,12 +855,14 @@ - For a server to support approach (b) (when client - chooses a flavor that is not a member of - sec_policy_parent) and (c), the put filehandle operation must NOT return - NFS4ERR_WRONGSEC when there is a security tuple mismatch. - Instead, it should be returned from the LOOKUP (or OPEN - by component name) that follows. + In order for a server to support approaches (b) + (for the case when a client chooses a flavor that is + not a member of sec_policy_parent) and (c), the put + filehandle operation cannot return NFS4ERR_WRONGSEC + when there is a security tuple mismatch. Instead, + it should be returned from the LOOKUP (or OPEN by + existing component name) that follows. + Since the above guideline does not contradict approach @@ -978,6 +994,59 @@
+
+
+ + The LINK and RENAME operations use both the current + and saved filehandles. When the current filehandle is + injected into a series of operations via a put filehandle + operation, the server MUST return NFS4ERR_WRONGSEC, + per . LINK and RENAME MAY + return NFS4ERR_WRONGSEC if the security policy of the + saved filehandle rejects the security flavor used in the + COMPOUND request's credentials. If the server does so, + then if there is no intersection between the security + policies of saved and current filehandles, this means it + will be impossible for client to perform the intended + LINK or RENAME operation. + + + + For example, suppose the client sends this COMPOUND + request: SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, + RENAME "c" "d", where filehandles bFH and aFH refer + to different directories. Suppose no common security + tuple exists between the security policies of aFH and + bFH. If the client sends the request using credentials + acceptable to bFH's security policy but not aFH's + policy, then the PUTFH aFH operation will fail with + NFS4ERR_WRONGSEC. After a SECINFO_NO_NAME request, + the client sends SEQUENCE, PUTFH bFH, SAVEFH, PUTFH + aFH, RENAME "c" "d", using credentials acceptable to + aFH's security policy, but not bFH's policy. The server + returns NFS4ERR_WRONGSEC on the RENAME operation. + + + + To prevent a client from an endless sequence of a + request containing LINK or RENAME, followed by a request + containing SECINFO_NO_NAME, the server MUST detect + when the security policies of the current and saved + filehandles have no mutually acceptable security tuple, + and MUST NOT NFS4ERR_WRONGSEC in that situation. Instead + the server MUST return NFS4ERR_XDEV. + + + + + Thus while a server MAY return NFS4ERR_WRONGSEC from + LINK and RENAME, the server implementor may reasonably decide + the consequences are not worth the security benefits, and + so allow the security policy of the current filehandle to + override that of the saved filehandle. + +
+
Index: nfsv41_middle_errors.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_errors.xml,v retrieving revision 1.63 diff -u -r1.63 nfsv41_middle_errors.xml --- nfsv41_middle_errors.xml 31 Mar 2008 23:18:57 -0000 1.63 +++ nfsv41_middle_errors.xml 18 Apr 2008 16:55:03 -0000 @@ -2123,6 +2123,7 @@ NFS4ERR_STALE, NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, + NFS4ERR_WRONGSEC, NFS4ERR_WRONG_TYPE, NFS4ERR_XDEV @@ -2662,6 +2663,7 @@ NFS4ERR_SERVERFAULT, NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, + NFS4ERR_WRONGSEC, NFS4ERR_XDEV Index: nfsv41_middle_fileattributes.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_fileattributes.xml,v retrieving revision 1.44 diff -u -r1.44 nfsv41_middle_fileattributes.xml --- nfsv41_middle_fileattributes.xml 19 Mar 2008 05:04:46 -0000 1.44 +++ nfsv41_middle_fileattributes.xml 18 Apr 2008 16:55:03 -0000 @@ -248,83 +248,119 @@ For quota_avail_hard, quota_avail_soft, and quota_used see their definitions below for the appropriate classification. + + + +
+ + Some REQUIRED and RECOMMENDED attributes are set-only, i.e. they + can be set via SETATTR but not retrieved via GETATTR. Similarly, some + REQUIRED and RECOMMENDED attributes are get-only, i.e. they + can be retrieved GETATTR but not set via SETATTR. If a client attempts + to set a get-only attribute or get a set-only attributes, the server + MUST return NFS4ERR_INVAL. + +
- - name + + The list of REQUIRED attributes appears in . + The meaning of hte columns of the table are: + + Name: the name of attribute + Id: the number assigned to the attribute. In + the event of conflicts between the assigned number and , the latter is authoritative. + Data Type: The XDR data type of the attribute. + + Acc: Access allowed to the attribute. R means + read-only (GETATTR may retrieve, SETATTR may not + set). W means write-only (SETATTR may set, GETATTR + may not retrieve). R W means read/write (GETATTR + may retrieve, SETATTR may set). + + + Defined in: the section of this specification that describes the + attribute. + + + + + Name Id Data Type Acc Defined in: - supported_attrs0bitmap4RD + supported_attrs0bitmap4R - type1nfs_ftype4RD + type1nfs_ftype4R - fh_expire_type2uint32_tRD + fh_expire_type2uint32_tR - change3uint64_tRD + change3uint64_tR - size4uint64_tR/W + size4uint64_tR W - link_support5boolRD + link_support5boolR - symlink_support6boolRD + symlink_support6boolR - named_attr7boolRD + named_attr7boolR - fsid8fsid4RD + fsid8fsid4R - unique_handles9boolRD + unique_handles9boolR - lease_time10nfs_lease4RD + lease_time10nfs_lease4R - rdattr_error11enumRD + rdattr_error11enumR - filehandle19nfs_fh4RD + filehandle19nfs_fh4R - suppattr_exclcreat75bitmap4RD + suppattr_exclcreat75bitmap4R @@ -333,330 +369,338 @@
- - name + + The RECOMMENDED attributes are defined in + . The meanings + of the column headers are the same as + ; see for the meanings. + + + + Name Id Data Type Acc Defined in: - acl12nfsace4<>R/W + acl12nfsace4<>R W - aclsupport13uint32_tRD + aclsupport13uint32_tR - archive14boolR/W + archive14boolR W - cansettime15boolRD + cansettime15boolR - case_insensitive16boolRD + case_insensitive16boolR - case_preserving17boolRD + case_preserving17boolR - change_policy60chg_policy4RD + change_policy60chg_policy4R - chown_restricted18boolRD + chown_restricted18boolR - dacl58nfsacl41R/W + dacl58nfsacl41R W - dir_notif_delay56nfstime4RD + dir_notif_delay56nfstime4R - dirent_notif_delay57nfstime4RD + dirent_notif_delay57nfstime4R - fileid20uint64_tRD + fileid20uint64_tR - files_avail21uint64_tRD + files_avail21uint64_tR - files_free22uint64_tRD + files_free22uint64_tR - files_total23uint64_tRD + files_total23uint64_tR - fs_charset_cap76uint32_tRD + fs_charset_cap76uint32_tR - fs_layout_type62layouttype4<>RD + fs_layout_type62layouttype4<>R - fs_locations24fs_locationsRD + fs_locations24fs_locationsR - fs_locations_info67*RD + fs_locations_info67*R - fs_status61fs4_statusRD + fs_status61fs4_statusR - hidden25boolR/W + hidden25boolR W - homogeneous26boolRD + homogeneous26boolR - layout_alignment66uint32_tRD + layout_alignment66uint32_tR - layout_blksize65uint32_tRD + layout_blksize65uint32_tR - layout_hint63layouthint4WRT + layout_hint63layouthint4  W - layout_type64layouttype4<>RD + layout_type64layouttype4<>R - maxfilesize27uint64_tRD + maxfilesize27uint64_tR - maxlink28uint32_tRD + maxlink28uint32_tR - maxname29uint32_tRD + maxname29uint32_tR - maxread30uint64_tRD + maxread30uint64_tR - maxwrite31uint64_tRD + maxwrite31uint64_tR - mdsthreshold68mdsthreshold4RD + mdsthreshold68mdsthreshold4R - mimetype32utf8<>R/W + mimetype32utf8<>R W - mode33mode4R/W + mode33mode4R W - mode_set_masked74mode_masked4WRT + mode_set_masked74mode_masked4  W - mounted_on_fileid55uint64_tRD + mounted_on_fileid55uint64_tR - no_trunc34boolRD + no_trunc34boolR - numlinks35uint32_tRD + numlinks35uint32_tR owner - 36utf8<>R/W + 36utf8<>R W owner_group - 37utf8<>R/W + 37utf8<>R W quota_avail_hard - 38uint64_tRD + 38uint64_tR quota_avail_soft - 39uint64_tRD + 39uint64_tR quota_used - 40uint64_tRD + 40uint64_tR - rawdev41specdata4RD + rawdev41specdata4R - retentevt_get71retention_get4RD + retentevt_get71retention_get4R - retentevt_set72retention_set4WRT + retentevt_set72retention_set4  W - retention_get69retention_get4RD + retention_get69retention_get4R - retention_hold73uint64_tR/W + retention_hold73uint64_tR W - retention_set70retention_set4WRT + retention_set70retention_set4  W - sacl59nfsacl41R/W + sacl59nfsacl41R W - space_avail42uint64_tRD + space_avail42uint64_tR - space_free43uint64_tRD + space_free43uint64_tR - space_total44uint64_tRD + space_total44uint64_tR - space_used45uint64_tRD + space_used45uint64_tR - system46boolR/W + system46boolR W time_access - 47nfstime4RD + 47nfstime4R - time_access_set48settime4WRT + time_access_set48settime4  W - time_backup49nfstime4R/W + time_backup49nfstime4R W - time_create50nfstime4R/W + time_create50nfstime4R W - time_delta51nfstime4RD + time_delta51nfstime4R - time_metadata52nfstime4RD + time_metadata52nfstime4R - time_modify53nfstime4RD + time_modify53nfstime4R - time_modify_set54settime4WRT + time_modify_set54settime4  W @@ -1589,7 +1633,7 @@ When retention is enabled, retention MUST extend to the data of the file, and the name of file. The server MAY extend retention - any other property of the file, including any subset of + to any other property of the file, including any subset of REQUIRED, RECOMMENDED, and named attributes, with the exceptions noted in this section. @@ -1604,11 +1648,13 @@
- If retention is enabled for the associated file, this - attribute's value represents the retention begin time of the - file object. This attribute's value is only readable with the - GETATTR operation and may not be modified by the SETATTR - operation. The value of the attribute consists of: + If retention is enabled for the associated file, + this attribute's value represents the retention + begin time of the file object. This attribute's + value is only readable with the GETATTR operation + and MUST NOT be modified by the SETATTR operation + (). The value of the + attribute consists of: @@ -1616,21 +1662,28 @@ long the file will be retained once retention is enabled. The field rg_begin_time is an array of up to one absolute time value. If the array is zero length, no beginning retention time - has been established, and retention is not enabled. If - rg_duration is equal to RET4_DURATION_INFINITE, the file, once + has been established, and retention is not enabled. + If rg_duration is equal to RET4_DURATION_INFINITE, the file, once retention is enabled, will be retained for an infinite duration. + + If (as soon as) rg_duration is zero, then rg_begin_time will be + of zero length, and again, retention is not (no longer) enabled. + +
- This attribute is used to set the retention duration and - optionally enable retention for the associated file object. - This attribute is only modifiable via SETATTR operation and - may not be read with the GETATTR operation. This attribute - corresponds to retention_get. The value of the attribute - consists of: + This attribute is used to set the retention + duration and optionally enable retention for + the associated file object. This attribute is + only modifiable via the SETATTR operation and + MUST NOT be retrieved by the GETATTR operation + (). + This attribute corresponds to retention_get. + The value of the attribute consists of: @@ -1638,7 +1691,7 @@ retention on the file object with the begin time of retention starting from the server's current time and date. The duration of the retention can also be provided if the - rs_duration array is of length one. The duration is time in + rs_duration array is of length one. The duration is the time in seconds from the begin time of retention, and if set to RET4_DURATION_INFINITE, the file is to be retained forever. If retention is enabled, with no duration specified in either @@ -1646,10 +1699,53 @@ zero seconds. The server MAY restrict the enabling of retention or the duration of retention on the basis of the ACE4_WRITE_RETENTION ACL permission. The enabling of - retention does not prevent the enabling of event-based + retention MUST NOT prevent the enabling of event-based retention nor the modification of the retention_hold attribute. + + The following rules apply to both the retention_set and + retentevt_set attributes. + + + + As long as retention is not enabled, the client + is permitted to decrease the duration. + + + + The duration can always be set to an + equal or higher value, even if retention is + enabled. Note that once retention is enabled, + the actual duration (as returned by the + retention_get or retentevt_get attributes, + see + or ), + is constantly counting down to zero (one unit + per second), unless the duration was set to + RET4_DURATION_INFINITE. Thus it will not be + possible for the client to precisely extend the + duration on a file that has retention enabled. + + + + While retention is enabled, attempts to disable + retention or decrease the retention's duration + MUST fail with the error NFS4ERR_INVAL. + + + + + If the principal attempting to change + retention_set or retentevt_set does not have + ACE4_WRITE_RETENTION permissions, the attempt + MUST fail with NFS4ERR_ACCESS. + + + + + +
+
@@ -1702,6 +1799,11 @@ holds does not prevent the enabling of event-based or non-event-based retention. + + If the principal attempting to change retention_hold does + not have ACE4_WRITE_RETENTION_HOLD permissions, + the attempt MUST fail with NFS4ERR_ACCESS. +
Index: nfsv41_middle_op_access.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_access.xml,v retrieving revision 1.6 diff -u -r1.6 nfsv41_middle_op_access.xml --- nfsv41_middle_op_access.xml 20 Nov 2007 23:48:48 -0000 1.6 +++ nfsv41_middle_op_access.xml 18 Apr 2008 16:55:03 -0000 @@ -26,11 +26,18 @@ provided. On success, the current filehandle retains its value. -Note that the supported field will contain only as many values as was -originally sent in the arguments. For example, if the client sends an -ACCESS operation with only the ACCESS4_READ value set and the server -supports this value, the server will return only ACCESS4_READ even if -it could have reliably checked other values. +Note that the reply's supported and access fields MUST NOT +contain more values than originally set in the request's +access field. For example, if the client sends an ACCESS +operation with just the ACCESS4_READ value set and the +server supports this value, the server MUST NOT set more +than ACCESS4_READ in the supported field even if it could +have reliably checked other values. + + + + The reply's access field MUST NOT contain more values than the + supported field. The results of this operation are necessarily advisory in nature. A @@ -58,11 +65,205 @@ Delete an existing directory entry. -Execute file (no meaning for a directory). +Execute a regular file (no meaning for a directory). On success, the current filehandle retains its value. + + ACCESS4_EXECUTE is a challenging semantic to implement because + NFS provides remote file access, not remote + execution. This leads to the following: + + + Whether a regular file is executable or not ought to be + the responsibility of the NFS client and not the server. And yet + the ACCESS operation is specified to seemingly require a server to + own that responsibility. + + + When a client executes a regular file, it has to + read the file from the server. Strictly speaking, + the server should not allow the client to read a file + being executed unless the user has read permissions + on the file. Requiring users and administers to set + read permissions on executable files in order to + access them over NFS is not going to be acceptable to + some people. Historically, NFS servers have allowed + a user to READ a file if the user has execute access + to the file. + + + + + + As a practical example, the UNIX specification states that an implementation + claiming conformance to UNIX may indicate in the + access() programming interface's result that a + privileged user has execute rights, even if no + execute permission bits are set on the regular file's + attributes. It is possible to claim conformance + to the UNIX specification and instead not indicate + execute rights in that situation, which is true for + some operating enviroments. Suppose the operating + environments of the client and server are implementing + the access() semantics for privileged users differently, + and the ACCESS operation implementations of the client + and server follow their respective access() semantics. + This can cause undesired behavior: + + + + Suppose the client's access() interface returns X_OK + if the user is privileged and no execute permission + bits are set on the regular file's attribute, and the + server's access() interface does not return X_OK in + that situation. Then the client will be unable to + execute files stored on the NFS server that could be + executed if stored on a non-NFS file system. + + + + Suppose the client's access() interface does + not return X_OK if the user is privileged, and no + execute permission bits are set on the regular file's + attribute, and the server's access() interface does + return X_OK in that situation. Then: + + + + The client will be able to execute files stored on + the NFS server that could be executed if stored on + a non-NFS file system, unless the client's execution + subsystem also checks for execute permission bits. + + + + Even if the execution subsystem is checking for + execute permission bits, there are more potential + issues. E.g. suppose the client is invoking access() + to build a "path search table" of all executable + files in the user's "search path", where the path + is a list of directories each containing executable + files. Suppose there are two files each in separate + directories of the search path, such that files have + the same component name. In the first directory + the file has no execute permission bits set, + and in the second directory the file has execute + bits set. The path search table will indicate that + the first directory has the executable file, but + the execute subsystem will fail to execute it. The + command shell might fail to try the second file in + the second directory. And even if it did, this is + a potential performance issue. Clearly the desired + outcome for the client is for the path search table + to not contain the first file. + + + + + + + + To deal the problems described above, the smart client, + stupid server principle is used. The client owns overall + responsibility for determining execute access and + relies on the server to parse the execution permissions + within the file's mode, acl, and dacl attributes. The + rules for the client and server follow: + + + + If the client is sending ACCESS in order to determine + if the user can read the file, the client SHOULD + set ACCESS4_READ in the request's access field. + + + + If the client's operating environment only grants + execution to the user if the user has execute access + according to the execute permissions in the mode, + acl, and dacl attributes, then if the client wants + to determine execute access, the client SHOULD send + an ACCESS request with ACCESS4_EXECUTE bit set in the + request's access field. + + + + If the client's operating environment grants execution + to the user even if the user does not have execute + access according to the execute permissions in the + mode, acl, and dacl attributes, then if the client + wants to determine execute access, it SHOULD send + an ACCESS request with both the ACCESS4_EXECUTE and + ACCESS4_READ bits set in the request's access field. This + way, if any read or execute permission grants the user + read or execute access (or if the server interprets + the user as privileged), as indicated by the presence + of ACCESS4_EXECUTE and/or ACCESS4_READ in the reply's + access field, the client will be able to grant the + user execute access to the file. + + + + + If the server supports execute permission bits, or some other + method for denoting executability (e.g. the suffix of the name + of the file might indicate execute), it MUST check + only execute permissions, not read permissions, when determining + whether the reply will have ACCESS4_EXECUTE set in the access + field or not. + The server MUST NOT also examine read permission bits when + determining whether the reply will have ACCESS4_EXECUTE + set in the access field or not. Even if the server's + operating environment would grant execute access to the + user (e.g., the user is privileged), the server MUST + NOT reply with ACCESS4_EXECUTE set in reply's access + field, unless there is at least one execute permission + bit set in the mode, acl, or dacl attributes. In the + case of acl and dacl, the "one execute permission bit" + MUST be an ACE4_EXECUTE bit set in an ALLOW ACE. + + + + If the server does not support execute permission + bits or some other method for denoting executability, it MUST NOT set ACCESS4_EXECUTE in the + reply's supported and access fields. If the client + set ACCESS4_EXECUTE in the ACCESS request's access + field, and ACCESS4_EXECUTE is not set in the reply's + supported field, then the client will have to send + an ACCESS request with the ACCESS4_READ bit set in + the request's access field. + + + + + If the server supports read permission bits, it MUST + only check for read permissions in the mode, acl, + and dacl attributes when it receives an ACCESS request + with ACCESS4_READ set the access field. The server + MUST NOT also examine execute permission bits when + determining whether the reply will have ACCESS4_READ + set in the access field or not. + + + + + Note that if the ACCESS reply has ACCESS4_READ + or ACCESS_EXECUTE set, then the user also has + permissions to OPEN () or + READ () the file. I.e., if + client sends an ACCESS request with the ACCESS4_READ + and ACCESS_EXECUTE set in the access field (or two + separate requests, one with ACCESS4_READ set, and the + other with ACCESS4_EXECUTE set), and the reply has + just ACCESS4_EXECUTE set in the access field (or just + one reply has ACCESS4_EXECUTE set), then the user has + authorization to OPEN or READ the file. + + +
@@ -85,8 +286,8 @@ will result in an access failure. The OPEN operation provides a point where the server can verify access to the file object and method to return that information to the client. The ACCESS operation is still -useful for directory operations or for use in the case the UNIX API -"access" is used on the client. +useful for directory operations or for use in the case the UNIX interface +access() is used on the client. The information returned by the server in response to an ACCESS call @@ -113,5 +314,6 @@ right. The ACCESS4_DELETE bit in the access mask returned will then be ignored by the client. +
Index: nfsv41_middle_op_close.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_close.xml,v retrieving revision 1.14 diff -u -r1.14 nfsv41_middle_op_close.xml --- nfsv41_middle_op_close.xml 31 Mar 2008 23:18:57 -0000 1.14 +++ nfsv41_middle_op_close.xml 18 Apr 2008 16:55:03 -0000 @@ -58,10 +58,10 @@ useful for operations that follow. To help find any uses of this stateid by clients, the server SHOULD return the invalid special stated (the "other" value is zero and the "seqid" field - is NFS4_MAXFILELEN). + is NFS4_UINT32_MAX, see ). - A CLOSE operation may make delegations grantable + A CLOSE operation may make delegations grantable where they were not previously. Servers may choose to respond immediately if there are pending delegation want requests or may respond to the situation at a later time. Index: nfsv41_middle_op_commit.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_commit.xml,v retrieving revision 1.6 diff -u -r1.6 nfsv41_middle_op_commit.xml --- nfsv41_middle_op_commit.xml 25 Feb 2008 20:51:37 -0000 1.6 +++ nfsv41_middle_op_commit.xml 18 Apr 2008 16:55:03 -0000 @@ -13,7 +13,7 @@
- The COMMIT operation forces or flushes data to stable storage for the + The COMMIT operation forces or flushes uncommitted, modified data to stable storage for the file specified by the current filehandle. The flushed data is that which was previously written with a WRITE operation which had the stable field set to UNSTABLE4. @@ -64,7 +64,7 @@ The server implementation of COMMIT is reasonably simple. If the server receives a full file COMMIT request, that is starting at offset 0 and count 0, it should do the equivalent of fsync()'ing the file. - Otherwise, it should arrange to have the cached data in the range + Otherwise, it should arrange to have the modified data in the range specified by offset and count to be flushed to stable storage. In both cases, any metadata associated with the file must be flushed to stable storage before returning. It is not an error for there to be @@ -77,8 +77,8 @@ are two reasons for wanting to commit a client buffer to stable storage. The first is that the client wants to reuse a buffer. In this case, the offset and count of the buffer are sent to the server - in the COMMIT request. The server then flushes any cached data based - on the offset and count, and flushes any metadata associated with the + in the COMMIT request. The server then flushes any modified data based + on the offset and count, and flushes any modified metadata associated with the file. It then returns the status of the flush and the write verifier. The other reason for the client to generate a COMMIT is for a full file flush, such as may be done at close. In this case, the client @@ -99,15 +99,17 @@ When a response is returned from either a WRITE or a COMMIT operation and it contains a write verifier that is different than previously returned by the server, the client will need to retransmit all of the - buffers containing uncommitted cached data to the server. How this is + buffers containing uncommitted data to the server. How this is to be done is up to the implementor. If there is only one buffer of - interest, then it should probably be sent back over in a WRITE request - with the appropriate stable parameter. If there is more than one + interest, then it should sent in a WRITE request + with the FILE_SYNC4 stable parameter. If there is more than one buffer, it might be worthwhile retransmitting all of the buffers in WRITE requests with the stable parameter set to UNSTABLE4 and then retransmitting the COMMIT operation to flush all of the data on the - server to stable storage. The timing of these retransmissions is left - to the implementor. + server to stable storage. However, if the server repeatably + returns from COMMIT a verifier that differs from that returned + by WRITE, the only way to ensure progress is to retransmit all + of the buffers with WRITE requests with the FILE_SYNC4 stable parameter. The above description applies to page-cache-based systems as well as Index: nfsv41_middle_op_create.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_create.xml,v retrieving revision 1.11 diff -u -r1.11 nfsv41_middle_op_create.xml --- nfsv41_middle_op_create.xml 21 Feb 2008 12:58:17 -0000 1.11 +++ nfsv41_middle_op_create.xml 18 Apr 2008 16:55:03 -0000 @@ -19,10 +19,10 @@ regular file or a named attribute. - The directory must be an object of type NF4DIR. If the current + The current filehandle must be a directory: an object of type NF4DIR. If the current filehandle is an attribute directory (type NF4ATTRDIR), the error NFS4ERR_WRONG_TYPE is returned. If the current file handle - designate any other type of object, the error NFS4ERR_NOTDIR + designates any other type of object, the error NFS4ERR_NOTDIR results. @@ -80,7 +80,7 @@ Conversely, it is possible the client will specify in createattrs an - owner attribute or group attribute or ACL that the principal indicated + owner attribute, group attribute, or ACL that the principal indicated the RPC call's credentials does not have permissions to create files for. The error to be returned in this instance is NFS4ERR_PERM. This applies to the OPEN operation too. @@ -89,7 +89,7 @@ If the current filehandle designates a directory for which another client holds a directory delegation, then, unless the delegation is such that the situation can be resolved by sending a notification, - the delegation must be recalled, and the operation cannot proceed + the delegation MUST be recalled, and the CREATE operation MUST NOT proceed until the delegation is returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be returned to requests made while delegation remains outstanding. Index: nfsv41_middle_op_create_session.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_create_session.xml,v retrieving revision 1.45 diff -u -r1.45 nfsv41_middle_op_create_session.xml --- nfsv41_middle_op_create_session.xml 25 Feb 2008 20:51:37 -0000 1.45 +++ nfsv41_middle_op_create_session.xml 18 Apr 2008 16:55:04 -0000 @@ -564,5 +564,9 @@ + + If the server cannot reserve space for the reply cache, it + MAY return NFS4ERR_NOSPC. +
Index: nfsv41_middle_op_delegreturn.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_delegreturn.xml,v retrieving revision 1.8 diff -u -r1.8 nfsv41_middle_op_delegreturn.xml --- nfsv41_middle_op_delegreturn.xml 17 Dec 2007 22:17:39 -0000 1.8 +++ nfsv41_middle_op_delegreturn.xml 18 Apr 2008 16:55:04 -0000 @@ -23,7 +23,7 @@ The server MAY require that the principal, security - flavor, and applicable, the GSS mechanism, combination + flavor, and if applicable, the GSS mechanism, combination that acquired the delegation also be the one to send DELEGRETURN on the file. This might not be possible if credentials for the principal are no longer Index: nfsv41_middle_op_getattr.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_getattr.xml,v retrieving revision 1.10 diff -u -r1.10 nfsv41_middle_op_getattr.xml --- nfsv41_middle_op_getattr.xml 29 Jan 2008 08:19:32 -0000 1.10 +++ nfsv41_middle_op_getattr.xml 18 Apr 2008 16:55:04 -0000 @@ -24,12 +24,12 @@ lowest attribute number first. - The server must return a value for each attribute that the client + The server MUST return a value for each attribute that the client requests if the attribute is supported by the server for the target file system. If the server does not support a particular attribute - on the target file system then it must not return the attribute value - and must not set the attribute bit in the result bitmap. The server - must return an error if it supports an attribute on the target + on the target file system then it MUST NOT return the attribute value + and MUST NOT set the attribute bit in the result bitmap. The server + MUST return an error if it supports an attribute on the target but cannot obtain its value. In that case, no attribute values will be returned. @@ -51,14 +51,14 @@
- When there is write delegation held by another client for file - in question and the set of attributes being interrogated includes - the size of change attributes. the server needs to obtain the actual + Suppose there is a write delegation held by another client for file + in question and size and/or change are among the set of attributes being interrogated. The server has two choices. + First, the server can obtain the actual current value of these attributes from the client holding the delegation - by using the CB_GETATTR callback. The server, particularly, when the - delegated client is unresponsive, choose instead to recall the - delegation in question. The GETATTR may not, in this case proceed - until of the following occurs: + by using the CB_GETATTR callback. Second, the server, particularly when the + delegated client is unresponsive, can recall the + delegation in question. The GETATTR MUST NOT proceed + until one of the following occurs: The requested attribute values are returned in the response to @@ -73,9 +73,10 @@ - Except where one of these happens - very quickly, one or more NFS4ERR_DELAY errors will be - returned to requests made while delegation remains outstanding. + Unless one of the above happens very quickly, + one or more NFS4ERR_DELAY errors will be returned if + while a delegation is outstanding. +
Index: nfsv41_middle_op_getfh.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_getfh.xml,v retrieving revision 1.5 diff -u -r1.5 nfsv41_middle_op_getfh.xml --- nfsv41_middle_op_getfh.xml 8 Nov 2007 04:15:21 -0000 1.5 +++ nfsv41_middle_op_getfh.xml 18 Apr 2008 16:55:04 -0000 @@ -23,6 +23,16 @@ On success, the current filehandle retains its value. + + As described in , GETFH is REQUIRED or RECOMMENDED to + immediately follow certain operations, and servers + are free to reject such operations + the client fails to insert + GETFH in the request as REQUIRED or RECOMMENDED. + provides additional + justification for why GETFH MUST follow OPEN. + +
Index: nfsv41_middle_op_link.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_link.xml,v retrieving revision 1.10 diff -u -r1.10 nfsv41_middle_op_link.xml --- nfsv41_middle_op_link.xml 19 Dec 2007 15:27:13 -0000 1.10 +++ nfsv41_middle_op_link.xml 18 Apr 2008 16:55:04 -0000 @@ -44,13 +44,13 @@ If a server does implement such restrictions and those restrictions include cases of NFSv4 opens preventing successful execution of a link, the server needs to recall any delegations which could - hide the existence of opens relevant to that decision. This is - because of the fact that when a client holds a delegation, the server - need not have accurate picture of the opens for that client, since + hide the existence of opens relevant to that decision. The reason + is that when a client holds a delegation, the server + might not have an accurate account of the opens for that client, since the client may execute OPENs and CLOSEs locally. The LINK operation - must be delayed only until a definitive result can be obtained. For - example, if there are multiple delegations and one of them establishes - an open whose presence would prevent the link, given the server's + must be delayed only until a definitive result can be obtained. E.g., + suppose there are multiple delegations and one of them establishes + an open whose presence would prevent the link. Given the server's semantics, NFS4ERR_FILE_OPEN may be returned to the caller as soon as that delegation is returned without waiting for other delegations to be returned. Similarly, if such opens are not associated with @@ -61,7 +61,7 @@ If the current filehandle designates a directory for which another client holds a directory delegation, then, unless the delegation is such that the situation can be resolved by sending a notification, - the delegation must be recalled, and the operation cannot be + the delegation MUST be recalled, and the operation cannot be performed successfully. until the delegation is returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be @@ -70,13 +70,14 @@ When the current filehandle designates a directory for which one or more directory delegations exist, then, when those delegations - request such notifications, NOTIFY4_ADD_ENTRY will be generated - as a result of this operation. + request such notifications, instead of a recall, + NOTIFY4_ADD_ENTRY will be generated + as a result of the LINK operation. If the current file system supports the numlinks attribute, and other clients have delegations to the file being linked, then those - delegations must be recalled and the operation may proceed until + delegations MUST be recalled and the LINK operation MUST NOT proceed until all delegations are returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be returned to requests made while delegation remains outstanding. @@ -91,20 +92,20 @@ The statement "file and the target directory must reside within the same file system on the server" means that the fsid fields in the attributes for the objects are the same. If they reside on - different file systems, the error NFS4ERR_XDEV, is returned. + different file systems, the error NFS4ERR_XDEV is returned. This error may be returned by some server when there is an internal partitioning of a file system which the LINK operation would violate. On some - servers, the filenames, "." and "..", are illegal as newname + servers, "." and ".." are illegal values for newname and the error NFS4ERR_BADNAME will be returned if they are specified. When the current filehandle designates a named attribute directory and the object to be linked (the saved filehandle) is not a named - attribute for the same object, the error NFS4ERR_XDEV must be + attribute for the same object, the error NFS4ERR_XDEV MUST be returned. When the saved filehandle designates a named attribute and the current filehandle is not the appropriate named attribute directory, the error NFS4ERR_XDEV MUST also be returned. Index: nfsv41_middle_op_lock.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_lock.xml,v retrieving revision 1.16 diff -u -r1.16 nfsv41_middle_op_lock.xml --- nfsv41_middle_op_lock.xml 31 Mar 2008 23:18:57 -0000 1.16 +++ nfsv41_middle_op_lock.xml 18 Apr 2008 16:55:04 -0000 @@ -14,27 +14,37 @@
The LOCK operation requests a byte-range lock for the byte range specified - by the offset and length parameters. The lock type is also specified - to be one of the nfs_lock_type4s. If this is a reclaim request, the + by the offset and length parameters, and lock type specified in + the locktype parameter. If this is a reclaim request, the reclaim parameter will be TRUE. Bytes in a file may be locked even if those bytes are not currently allocated to the file. To lock the file from a specific offset through the end-of-file (no matter how long the file actually is) use - a length field with all bits set to 1 (one). If the length is zero, - or if a length which is not all bits set to one is specified, and - length when added to the offset exceeds the maximum 64-bit unsigned - integer value, the error NFS4ERR_INVAL will result. + a length field equal to NFS4_UINT64_MAX. + The server MUST return NFS4ERR_INVAL under the following + combinations of length and offset: + + + + Length is equal to zero. + + + Length is not equal to NFS4_UINT64_MAX, and the sum of length + and offset exceeds NFS4_UINT64_MAX. + + + - 32 bit servers are servers that support locking for + 32-bit servers are servers that support locking for byte offsets that fit within 32 bits (i.e. less than - or equal to 0xFFFFFFFF). If the client specifies a + or equal to NFS4_UINT32_MAX). If the client specifies a range that overlaps one or more bytes beyond offset - 0xFFFFFFFF, but does not end at the maximum 64 bit - offset (i.e. 0xFFFFFFFFFFFFFFFF), such a 32-bit - server MUST return the error NFS4ERR_BAD_RANGE. + NFS4_UINT32_MAX, but does not end at offset + NFS4_UINT64_MAX, then such a 32-bit server MUST return the + error NFS4ERR_BAD_RANGE. If the server returns NFS4ERR_DENIED, @@ -46,11 +56,12 @@ the LOCK request. The locker4 structure is a switched union that indicates whether the client has already created byte-range locking state associated with the current open file and lock-owner. In the - case in which it has, the argument is just a stateid for the set of + case in which it has, the argument is just a stateid representing + the set of locks associated with that open file and lock-owner, together with a lock_seqid value which MAY be any value and MUST be ignored by the server. - In the case where no such state has been established, or the client + In the case where no byte-range locking state has been established, or the client does not have the stateid available, the argument contains the stateid of the open file with which this lock is to be associated, together with the lock-owner with which the lock is to be associated. @@ -60,16 +71,45 @@ a lock stateid. - The client field of lock_owner, and all seqid values in - the arguments MAY be any value and MUST be ignored by the server. - The client ID with which all owners and stateids - are associated - is the client ID associated with the session on which the request - was sent. The client ID appearing in a LOCK4denied structure - is the actual client associated with the conflicting lock, whether - this is the client ID associated with the current session, or a - different one. + The following fields of the locker parameter MAY be + set to any value by the client and MUST be ignored + by the server: + + + + The clientid field of the lock_owner + field of the open_owner field + (locker.open_owner.lock_owner.clientid). The + reason the server MUST ignore the clientid field + is that the server MUST derive the client ID from + the sessionid from the SEQUENCE operation of the + COMPOUND request. + + + + The open_seqid and lock_seqid fields of the + open_owner field (locker.open_owner.open_seqid and + locker.open_owner.lock_seqid). + + + + The lock_seqid field of the lock_owner field + (locker.lock_owner.lock_seqid). + + + + + + + Note that the client ID appearing in a LOCK4denied + structure is the actual client associated with the + conflicting lock, whether this is the client ID + associated with the current session, or a different + one. Thus if the server returns NFS4ERR_DENIED, + it MUST set clientid of the owner field of the + denied field. + If the current filehandle is not an ordinary file, an error will be returned to the client. In the case that the current filehandle @@ -128,12 +168,12 @@ When one or more clients hold read delegations, any LOCK request - where the server is implementing mandatory locking semantics, must + where the server is implementing mandatory locking semantics, MUST result in the recall of all such delegations. The LOCK request may not be granted until all such delegations are return or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be - returned to requests made while delegation remains outstanding. + returned to requests made while the delegation remains outstanding.
Index: nfsv41_middle_op_lockt.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_lockt.xml,v retrieving revision 1.11 diff -u -r1.11 nfsv41_middle_op_lockt.xml --- nfsv41_middle_op_lockt.xml 21 Feb 2008 12:58:17 -0000 1.11 +++ nfsv41_middle_op_lockt.xml 18 Apr 2008 16:55:05 -0000 @@ -31,10 +31,13 @@ as for LOCK. - The client ID field of the owner should be specified as zero. The - client ID used for ownership comparisons is that associated with the - session on which the request is sent. If the client ID field is - other than zero, the server MUST return the error NFS4ERR_INVAL. + The clientid field of the owner MAY be set to + any value by the client and MUST be ignored by + the server. The reason the server MUST ignore the + clientid field is that the server MUST derive the + client ID from the sessionid from the SEQUENCE + operation of the COMPOUND request. + If the current filehandle is not an ordinary file, an error will be @@ -61,21 +64,26 @@ LOCKT uses a lock_owner4 rather a stateid4, as is used in LOCK to identify the owner. This is because the client does not have to open the file to test for the existence of a lock, so - a stateid may not be available. + a stateid might not be available. - The test for conflicting locks should exclude locks for the current - lock-owner. Note that since such locks are not examined the possible - existence of overlapping ranges may not affect the results of LOCKT. - If the server does examine locks that match the lock-owner for the - purpose of range checking, NFS4ERR_LOCK_RANGE may be returned.. In - the event that it returns NFS4_OK, clients may do a LOCK and receive - NFS4ERR_LOCK_RANGE on the LOCK request because of the flexibility - provided to the server. + As noted in , some + servers may return NFS4ERR_LOCK_RANGE to certain (otherwise + non-conflicting) lock requests that overlap ranges already + granted to the current lock-owner. + + + The LOCKT operation's test for conflicting locks SHOULD exclude + locks for the current lock-owner, and thus should return NFS4_OK in + such cases. Note that this means that a server might return + NFS4_OK to a LOCKT request even though a LOCK request for the + same range and lock owner would fail with NFS4ERR_LOCK_RANGE. + + When a client holds a write delegation, it may choose - (See ) to handle LOCK + (see ) to handle LOCK requests locally. In such a case, LOCKT requests will similarly be handled locally. Index: nfsv41_middle_op_lookupp.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_lookupp.xml,v retrieving revision 1.8 diff -u -r1.8 nfsv41_middle_op_lookupp.xml --- nfsv41_middle_op_lookupp.xml 10 Nov 2007 04:53:25 -0000 1.8 +++ nfsv41_middle_op_lookupp.xml 18 Apr 2008 16:55:05 -0000 @@ -26,7 +26,7 @@ root or top of the server's file tree. - As for LOOKUP, LOOKUPP will also cross mountpoints. + As is the case with LOOKUP, LOOKUPP will also cross mountpoints. If the current filehandle is not a directory or named attribute @@ -37,10 +37,9 @@ configured for the parent directory, then the server SHOULD return NFS4ERR_WRONGSEC (a future minor revision of NFSv4 may upgrade this to MUST) in the LOOKUPP response. However, if the - server does so, it MUST support the new SECINFO_NO_NAME - operation, so that the client can gracefully determine the - correct security flavor. See the discussion of the - SECINFO_NO_NAME operation for a description. + server does so, it MUST support the SECINFO_NO_NAME + operation (), so that the client can gracefully determine the + correct security flavor. If the current filehandle is a named attribute directory that is Index: nfsv41_middle_op_mandlist.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_mandlist.xml,v retrieving revision 1.5 diff -u -r1.5 nfsv41_middle_op_mandlist.xml --- nfsv41_middle_op_mandlist.xml 29 Jan 2008 08:19:32 -0000 1.5 +++ nfsv41_middle_op_mandlist.xml 18 Apr 2008 16:55:05 -0000 @@ -9,12 +9,11 @@ OPTIONAL to implement or MUST NOT implement. The designation of MUST NOT implement is reserved for those operations that were defined in - NFSv4.0 and they MUST NOT be implemented in NFSv4.1. These - operations are limited to those replaced by the Sessions - functionality of NFSv4.1. + NFSv4.0 and MUST NOT be implemented in NFSv4.1. - For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation is for + For the most part, the REQUIRED, RECOMMENDED, or OPTIONAL designation for + operations sent by the client is for the server implementation. The client is generally required to implement the operations needed for the operating environment for which it serves. For example, a read-only NFSv4.1 client would @@ -22,6 +21,16 @@ to do so. + The REQUIRED or OPTIONAL designation for + callback operations sent by the server is for both the client + and server. Generally, the client has the option of + creating the backchannel and sending the operations on the + fore channel that will be a catalyst for the server sending + callback operations. A partial + exception is CB_RECALL_SLOT; the only way the client can + avoid supporting this operation is by not creating a backchannel. + + Since this is a summary of the operations and their designation, there are subtleties that are not presented here. Therefore, if there is a question of the requirements of implementation, the Index: nfsv41_middle_op_nverify.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_nverify.xml,v retrieving revision 1.7 diff -u -r1.7 nfsv41_middle_op_nverify.xml --- nfsv41_middle_op_nverify.xml 29 Jan 2008 08:19:32 -0000 1.7 +++ nfsv41_middle_op_nverify.xml 18 Apr 2008 16:55:05 -0000 @@ -15,7 +15,7 @@ This operation is used to prefix a sequence of operations to be performed if one or more attributes have changed on some file system - object. If all the attributes match then the error NFS4ERR_SAME must + object. If all the attributes match then the error NFS4ERR_SAME MUST be returned. @@ -31,12 +31,16 @@ it has:
- PUTFH (public) - LOOKUP "foobar" + SEQUENCE + PUTFH fh NVERIFY attrbits attrs READ 0 32767
+ Contrast this with NFSv3, which would first send a GETATTR in + one request/reply round trip, and then if attributes indicated that + the client's cache was stale, then send a READ in another request/reply + round trip. In the case that a RECOMMENDED attribute is specified in the NVERIFY @@ -45,7 +49,7 @@ client. - When the attribute rdattr_error or any write-only attribute (e.g. + When the attribute rdattr_error or any set-only attribute (e.g. time_modify_set) is specified, the error NFS4ERR_INVAL is returned to the client. Index: nfsv41_middle_op_open.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_open.xml,v retrieving revision 1.33 diff -u -r1.33 nfsv41_middle_op_open.xml --- nfsv41_middle_op_open.xml 19 Mar 2008 05:04:46 -0000 1.33 +++ nfsv41_middle_op_open.xml 18 Apr 2008 16:55:06 -0000 @@ -35,6 +35,12 @@ include a component of a file name. + + Upon success (which might entail creation of a new + file), the current filehandle is replaced by that + of the created or existing object. + + If the current filehandle is a named attribute @@ -63,8 +69,8 @@ If GUARDED4 is specified, the server checks for the presence of a duplicate object by name before - performing the create. If a duplicate exists, an - error of NFS4ERR_EXIST is returned as the status. + performing the create. If a duplicate exists, + NFS4ERR_EXIST is returned. If the object does not exist, the request is performed as described for UNCHECKED4. @@ -116,15 +122,16 @@ suppattr_exclcreat, the server MUST return NFS4ERR_INVAL. The response field, attrset indicates both which attributes the server set from cva_attrs, and which attributes the - server used to store the verifier. The client can logically - AND cva_attrs.attrmask with attrset to determine which attributes + server used to store the verifier. As described + in , the client can compare + cva_attrs.attrmask with attrset to determine which attributes were used to store the verifier. With the addition of persistent sessions and pNFS, under some conditions EXCLUSIVE4 MUST NOT - be used by the client or supported the server. + be used by the client or supported by the server. The following table summarizes the appropriate and mandated exclusive create methods for implementations of NFSv4.1: @@ -161,9 +168,9 @@ If CREATE_SESSION4_FLAG_PERSIST is set in the results - of CREATE_SESSION the reply cache is persistent. + of CREATE_SESSION the reply cache is persistent (see ). If the EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the - results from EXCHANGE_ID, the server is a pNFS server. + results from EXCHANGE_ID, the server is a pNFS server (see ). If the client attempts to use EXCLUSIVE4 on a persistent session, or a session derived from a EXCHGID4_FLAG_USE_PNFS_MDS client ID, the server MUST return @@ -189,30 +196,35 @@ obtained atomically with respect to the link creation. - Upon successful creation, the current filehandle is replaced by that - of the new object. + The OPEN operation provides for Windows share + reservation capability with the use of the + share_access and share_deny fields of the OPEN + arguments. The client specifies at OPEN the required + share_access and share_deny modes. For clients + that do not directly support SHAREs (i.e. UNIX), the + expected deny value is DENY_NONE. In the case that + there is a existing SHARE reservation that conflicts + with the OPEN request, the server returns the error + NFS4ERR_SHARE_DENIED. For additional discussion of + SHARE semantics see . + - The OPEN operation provides for Windows share reservation capability - with the use of the share_access and share_deny fields of the OPEN - arguments. The client specifies at OPEN the required share_access and - share_deny modes. For clients that do not directly support SHAREs - (i.e. UNIX), the expected deny value is DENY_NONE. In the case that - there is a existing SHARE reservation that conflicts with the OPEN - request, the server returns the error NFS4ERR_SHARE_DENIED. - For each OPEN, - the client must provide a value for the owner - field for the OPEN argument. The client ID associated with the owner - is not derived from the client field of the owner parameter but is - instead the client ID associated with the session on which the request - is sent. If the client ID field of the owner parameter is not zero, - the server MUST return an NFS4ERR_INVAL error. - For additional discussion of - SHARE semantics see . + For each OPEN, the client provides a value for + the owner field of the OPEN argument. The owner + field is of data type open_owner4, and contains a + field called clientid and a field called owner. The + client can set the clientid field to any value and + the server MUST ignore it. Instead the server MUST + derive the client ID from the sessionid of the + SEQUENCE operation of the COMPOUND request. + - The seqid value is not used in NFSv4.1, but it MAY be any value and - the server MUST ignore it. + The seqid field of the request is not used in + NFSv4.1, but it MAY be any value and the server MUST + ignore it. + In the case that the client is recovering state from a server failure, @@ -384,9 +396,9 @@ - In the case of a OPEN which specifies a size of zero (e.g. truncation) + In the case of an OPEN which specifies a size of zero (e.g. truncation) and the file has named attributes, the named attributes are left as - is. They are not removed. + is and are not removed. @@ -422,7 +434,8 @@ client sends one or more of the new flags, then in the event the server does not return a delegation, it MUST return a delegation type of - OPEN_DELEGATE_NONE_EXT. od_whynone indicates why + OPEN_DELEGATE_NONE_EXT. The field od_whynone in the reply + indicates why no delegation was returned and will be one of: @@ -431,7 +444,7 @@ There is a conflicting delegation or open on the file. - + Resource limitations prevent the server from granting a delegation. @@ -559,7 +572,7 @@ verifier in stable storage. For file systems that do not provide a mechanism for the storage of arbitrary file attributes, the server may use one or more elements of the object metadata to store the - verifier. The verifier must be stored in stable storage to prevent + verifier. The verifier MUST be stored in stable storage to prevent erroneous failure on retransmission of the request. It is assumed that an exclusive create is being performed because exclusive semantics are critical to the application. Because of the expected usage, exclusive @@ -657,17 +670,17 @@ After the client has performed a successful exclusive create, the attrset response indicates which attributes were used to store the verifier. - If EXCLUSIVE4 was used, any attribute set in - attrset was used for the verifier. If EXCLUSIVE4_1 + If EXCLUSIVE4 was used, the attributes set in + attrset were used for the verifier. If EXCLUSIVE4_1 was used, the client determines the attributes used for the verifier by comparing attrset with - cva_attrs.attrmask; any bits set in former but + cva_attrs.attrmask; any bits set in the former but not the latter identify the attributes used store the verifier. The client MUST immediately send a - SETATTR on attributes used to store the verifier. + SETATTR to set attributes used to store the verifier. Until it does so, the attributes used to store the verifier cannot be relied upon. The subsequent - SETATTR must not occur in the same COMPOUND request + SETATTR MUST NOT occur in the same COMPOUND request as the OPEN. @@ -688,10 +701,10 @@ - For SHARE reservations, the client must specify a value for + For SHARE reservations, the client MUST specify a value for share_access that is one of READ, WRITE, or BOTH. For share_deny, the - client must specify one of NONE, READ, WRITE, or BOTH. If the client - fails to do this, the server must return NFS4ERR_INVAL. + client MUST specify one of NONE, READ, WRITE, or BOTH. If the client + fails to do this, the server MUST return NFS4ERR_INVAL. Based on the share_access value (READ, WRITE, or BOTH) the client should @@ -702,11 +715,31 @@ second-guess the server's decisions, as access rights may change and may be subject to server administrative controls outside the ACL framework. If the requester is not authorized to READ or WRITE - (depending on the share_access value), the server must return - NFS4ERR_ACCESS. Note that since the NFSv4.1 protocol does not - impose any requirement that READs and WRITEs sent for an open file - have the same credentials as the OPEN itself, the server still must do - appropriate access checking on the READs and WRITEs themselves. + (depending on the share_access value), the server MUST return + NFS4ERR_ACCESS. + + + + Note that if the client ID was not created + with EXCHGID4_FLAG_BIND_PRINC_STATEID set in + the reply to EXCHANGE_ID, then the server MUST + NOT impose any requirement that READs and WRITEs + sent for an open file have the same credentials + as the OPEN itself, and the server is REQUIRED to + perform access checking on the READs and WRITEs + themselves. Otherwise, if the reply to EXCHANGE_ID + did have EXCHGID4_FLAG_BIND_PRINC_STATEID set, + then with one exception, the credentials used in the OPEN request MUST + match those used in the READs and WRITEs, and the + stateids in the READs and WRITEs MUST match, or be + derived from the stateid from the reply to OPEN. + The exception is if SP4_SSV or SP4_MACH_CRED state + protection is used, and the spo_must_allow + result of EXCHANGE_ID includes the READ and/or WRITE + operations. In that case, the machine or SSV + credential will be allowed to issue READ and/or WRITE. + See . + If the component provided to OPEN is a symbolic link, the error @@ -730,7 +763,7 @@ If another client has a delegation of the file being opened that conflicts with open being done (sometimes depending of the share_access or share_deny value specified), - the delegation(s) must be recalled, and the + the delegation(s) MUST be recalled, and the operation cannot proceed until each such delegation is returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be @@ -758,7 +791,7 @@ the current filehandle designates a directory for which another client holds a directory delegation, then, unless the delegation is such that the situation can be resolved by sending a notification, - the delegation must be recalled, and the operation cannot proceed + the delegation MUST be recalled, and the operation cannot proceed until the delegation is returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be returned to requests made while delegation remains outstanding. @@ -788,6 +821,9 @@ another client does not attempt to make a conflicting access to the same file. + + See also . + Index: nfsv41_middle_op_open_downgrade.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_open_downgrade.xml,v retrieving revision 1.11 diff -u -r1.11 nfsv41_middle_op_open_downgrade.xml --- nfsv41_middle_op_open_downgrade.xml 21 Feb 2008 12:58:17 -0000 1.11 +++ nfsv41_middle_op_open_downgrade.xml 18 Apr 2008 16:55:06 -0000 @@ -13,25 +13,64 @@
- This operation is used to adjust the share_access and share_deny bits + This operation is used to adjust the access and deny states for a given open. This is necessary when a given open-owner opens the - same file multiple times with different share_access and share_deny - flags. In this situation, a close of one of the opens may change the + same file multiple times with different access and deny + values. In this situation, a close of one of the opens may change the appropriate share_access and share_deny flags to remove bits associated with opens no longer in effect. - The share_access and share_deny bits specified in this operation - replace the current ones for the specified open file. The - share_access and share_deny bits specified must be exactly equal to - the union of the share_access and share_deny bits specified for some - subset of the OPENs in effect for current open-owner on the current - file. If that constraint is not respected, the server may return - the error NFS4ERR_INVAL. - Since share_access and share_deny bits are - subsets of those already granted, it is not possible for this request - to be denied because of conflicting share reservations. + Valid values for the share_access field are: + OPEN4_SHARE_ACCESS_READ, OPEN4_SHARE_ACCESS_WRITE, + or OPEN4_SHARE_ACCESS_BOTH. If the client + specifies other values, the server MUST reply with + NFS4ERR_INVAL. + + + + Valid values for the share_deny field are: + OPEN4_SHARE_DENY_NONE, OPEN4_SHARE_DENY_READ, + OPEN4_SHARE_DENY_WRITE, or OPEN4_SHARE_DENY_BOTH. If + the client specifies other values, the server MUST + reply with NFS4ERR_INVAL. + + + + + After checking for valid values of share_access and + share_deny, the server replaces the current access + and deny modes on the file with share_access and + share_deny subject to the following constraints: + + + The bits in share_access SHOULD equal the union of the share_access + bits (not including OPEN4_SHARE_WANT_* bits) + specified for some subset of the OPENs + in effect for the current open-owner on the current + file. + + + + The bits in share_deny SHOULD equal the union of the + share_deny bits specified for some subset + of the OPENs in effect for the current open-owner + on the current file. + + + + + If the above constraints are not respected, + the server SHOULD return the error NFS4ERR_INVAL. + Since share_access and share_deny bits should be + subsets of those already granted, short of a defect + in the client or server implementation, it is not + possible for the OPEN_DOWNGRADE request to be denied + because of conflicting share reservations. + + + The seqid argument is not used in NFSv4.1, MAY be any value, and MUST be ignored by the server. Index: nfsv41_middle_op_putfh.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_putfh.xml,v retrieving revision 1.6 diff -u -r1.6 nfsv41_middle_op_putfh.xml --- nfsv41_middle_op_putfh.xml 31 Mar 2008 23:18:57 -0000 1.6 +++ nfsv41_middle_op_putfh.xml 18 Apr 2008 16:55:06 -0000 @@ -32,7 +32,7 @@
- Commonly used as the first operator in an NFS request to set the + Commonly used as the second operator (after SEQUENCE) in a COMPOUND request to set the context for following operations.
Index: nfsv41_middle_op_readdir.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_readdir.xml,v retrieving revision 1.6 diff -u -r1.6 nfsv41_middle_op_readdir.xml --- nfsv41_middle_op_readdir.xml 8 Nov 2007 04:15:21 -0000 1.6 +++ nfsv41_middle_op_readdir.xml 18 Apr 2008 16:55:06 -0000 @@ -26,35 +26,42 @@ is provided by the server on a previous READDIR request. - The cookieverf value should be set to 0 (zero) when the cookie value - is 0 (zero) (first directory read). On subsequent requests, it should - be a cookieverf as returned by the server. The cookieverf must match - that returned by the READDIR in which the cookie was acquired. - If the server determines that the cookieverf is no longer valid for - the directory, the error NFS4ERR_NOT_SAME must be returned. + The request's cookieverf field should be set to 0 + (zero) when the request's cookie field is 0 (zero) + (first directory read). On subsequent requests, the + cookieverf field must match the cookieverf returned + by the READDIR in which the cookie was acquired. + If the server determines that the cookieverf + is no longer valid for the directory, the error + NFS4ERR_NOT_SAME must be returned. + - The dircount portion of the argument is a hint of the maximum number + The dircount field of the request is a hint of the maximum number of bytes of directory information that should be returned. This value - represents the length of the names of the directory entries and the + represents the total length of the names of the directory entries and the cookie value for these entries. This length represents the XDR encoding of the data (names and cookies) and not the length in the native format of the server. - The maxcount value of the argument is the maximum number of bytes for - the result. This maximum size represents all of the data being - returned within the READDIR4resok structure and includes the XDR - overhead. The server may return less data. If the server is unable - to return a single directory entry within the maxcount limit, the - error NFS4ERR_TOOSMALL will be returned to the client. + The maxcount field of the request represents the maximum + total size of all of the data being returned within + the READDIR4resok structure and includes the XDR + overhead. The server MAY return less data. If the + server is unable to return a single directory entry + within the maxcount limit, the error NFS4ERR_TOOSMALL + MUST be returned to the client. + + + + Finally, the request's attr_request field represents + the list of attributes to be returned for each + directory entry supplied by the server. + - Finally, attr_request represents the list of attributes to be returned - for each directory entry supplied by the server. - - - On successful return, the server's response will provide a list of + A successful reply consists of a list of directory entries. Each of these entries contains the name of the directory entry, a cookie value for that entry, and the associated attributes as requested. The "eof" flag has a value of TRUE if there @@ -62,18 +69,18 @@ The cookie value is only meaningful to the server and is used - as a "bookmark" for the directory entry. As mentioned, this cookie + as a cursor for the directory entry. As mentioned, this cookie is used by the client for subsequent READDIR operations so that it may continue reading a directory. The cookie is similar in concept to a - READ offset but should not be interpreted as such by the client. - Ideally, the cookie value should not change if the directory is + READ offset but MUST NOT be interpreted as such by the client. + Ideally, the cookie value SHOULD NOT change if the directory is modified since the client may be caching these values. In some cases, the server may encounter an error while obtaining the attributes for a directory entry. Instead of returning an error for the entire READDIR operation, the server can instead return the - attribute 'fattr4_rdattr_error'. With this, the server is able to + attribute rdattr_error (). With this, the server is able to communicate the failure to the client and not fail the entire operation in the instance of what might be a transient failure. Obviously, the client must request the fattr4_rdattr_error attribute @@ -83,9 +90,9 @@ For some file system environments, the directory entries "." and ".." - have special meaning and in other environments, they may not. If the - server supports these special entries within a directory, they should - not be returned to the client as part of the READDIR response. To + have special meaning and in other environments, they do not. If the + server supports these special entries within a directory, they SHOULD + NOT be returned to the client as part of the READDIR response. To enable some client environments, the cookie values of 0, 1, and 2 are to be considered reserved. Note that the UNIX client will use these values when combining the server's response and local representations @@ -93,8 +100,8 @@ application. - For READDIR arguments, cookie values of 1 and 2 should not be used and - for READDIR results cookie values of 0, 1, and 2 should not be + For READDIR arguments, cookie values of 1 and 2 SHOULD NOT be used and + for READDIR results cookie values of 0, 1, and 2 SHOULD NOT be returned. @@ -103,35 +110,39 @@
- The server's file system directory representations can differ greatly. - A client's programming interfaces may also be bound to the local - operating environment in a way that does not translate well into the - NFS protocol. Therefore the use of the dircount and maxcount fields - are provided to allow the client the ability to provide guidelines to - the server. If the client is aggressive about attribute collection - during a READDIR, the server has an idea of how to limit the encoded - response. The dircount field provides a hint on the number of entries - based solely on the names of the directory entries. Since it is a - hint, it may be possible that a dircount value is zero. In this case, - the server is free to ignore the dircount value and return directory - information based on the specified maxcount value. + The server's file system directory representations + can differ greatly. A client's programming + interfaces may also be bound to the local operating + environment in a way that does not translate well + into the NFS protocol. Therefore the use of the + dircount and maxcount fields are provided to enable + the client to provide hints to the server. If the + client is aggressive about attribute collection + during a READDIR, the server has an idea of how to + limit the encoded response. + + + + If dircount is zero, the server bounds the reply's + size based on request's maxcount field. + The cookieverf may be used by the server to help manage cookie values that may become stale. It should be a rare occurrence that a server is unable to continue properly reading a directory with the provided - cookie/cookieverf pair. The server should make every effort to avoid - this condition since the application at the client may not be able to + cookie/cookieverf pair. The server SHOULD make every effort to avoid + this condition since the application at the client might be unable to properly handle this type of failure. The use of the cookieverf will also protect the client from using - READDIR cookie values that may be stale. For example, if the file - system has been migrated, the server may or may not be able to use the + READDIR cookie values that might be stale. For example, if the file + system has been migrated, the server might or might not be able to use the same cookie values to service READDIR as the previous server used. With the client providing the cookieverf, the server is able to provide the appropriate response to the client. This prevents the - case where the server may accept a cookie value but the underlying + case where the server accepts a cookie value but the underlying directory has changed and the response is invalid from the client's context of its previous READDIR. Index: nfsv41_middle_op_readlink.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_readlink.xml,v retrieving revision 1.6 diff -u -r1.6 nfsv41_middle_op_readlink.xml --- nfsv41_middle_op_readlink.xml 25 Nov 2007 00:35:58 -0000 1.6 +++ nfsv41_middle_op_readlink.xml 18 Apr 2008 16:55:06 -0000 @@ -18,10 +18,15 @@
- READLINK reads the data associated with a symbolic link. The data is - a UTF-8 string that is opaque to the server. That is, whether created - by an NFS client or created locally on the server, the data in a - symbolic link is not interpreted when created, but is simply stored. + READLINK reads the data associated with a symbolic + link. Depending on the value of the UTF-8 capability + attribute (), the data is encoded + in UTF-8. + Whether created by an NFS client or created locally + on the server, the data in a symbolic link is not + interpreted (except possibly to check for proper UTF-8 + encoding) when created, but is simply stored. + On success, the current filehandle retains its value. @@ -40,7 +45,7 @@ The READLINK operation is only allowed on objects of type NF4LNK. - The server should return the error NFS4ERR_WRONG_TYPE, if the + The server should return the error NFS4ERR_WRONG_TYPE if the object is not of type NF4LNK.
Index: nfsv41_middle_op_remove.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_remove.xml,v retrieving revision 1.13 diff -u -r1.13 nfsv41_middle_op_remove.xml --- nfsv41_middle_op_remove.xml 20 Dec 2007 16:22:56 -0000 1.13 +++ nfsv41_middle_op_remove.xml 18 Apr 2008 16:55:06 -0000 @@ -27,8 +27,12 @@ removal. - If the target has a length of 0 (zero), or if target does not obey - the UTF-8 definition, the error NFS4ERR_INVAL will be returned. + If the target has a length of 0 (zero), or if + target does not obey the UTF-8 definition (and + the server is enforcing UTF-8 encoding, see ), the error NFS4ERR_INVAL will + be returned. + On success, the current filehandle retains its value. @@ -51,16 +55,25 @@ a REMOVE operation in the same COMPOUND call. - The concept of last reference is server specific. However, if the - numlinks field in the previous attributes of the object had the value - 1, the client should not rely on referring to the object via a - filehandle. Likewise, the client should not rely on the resources - (disk space, directory entry, and so on) formerly associated with the - object becoming immediately available. Thus, if a client needs to be - able to continue to access a file after using REMOVE to remove it, the - client should take steps to make sure that the file will still be - accessible. The usual mechanism used is to RENAME the file from its - old name to a new hidden name. + The concept of last reference is server + specific. However, if the numlinks field in the + previous attributes of the object had the value 1, + the client should not rely on referring to the + object via a filehandle. Likewise, the client + should not rely on the resources (disk space, + directory entry, and so on) formerly associated + with the object becoming immediately available. + Thus, if a client needs to be able to continue to + access a file after using REMOVE to remove it, the + client should take steps to make sure that the file + will still be accessible. While the traditional + mechanism used is to RENAME the file from its old + name to a new hidden name, the NFSv4.1 OPEN operation + MAY return a result flag, OPEN4_RESULT_PRESERVE_UNLINKED, + which indicates to the client that the file will be + preserved if the file has an outstanding open (see ). + If the server finds that the file is still open when the REMOVE @@ -78,60 +91,94 @@ the server MAY continue to allow access to the file via its filehandle. + + The server MUST NOT delete the directory + entry if the reply from OPEN had the flag + OPEN4_RESULT_PRESERVE_UNLINKED set. + + + - The server MAY choose to implement its own restrictions on removal - of files while they are open such that REMOVE or a removal that occurs - as part of RENAME may not be done when the file being removed is if - the open is done by particular protocols, or with particular options - or access modes. In all cases in which a decision is made to not - allow the file's directory entry be removed because of an open, - the error NFS4ERR_FILE_OPEN is returned. - - - Where the determination above cannot be made definitively because - delegations are being held, they must be recalled to allow - processing of the REMOVE to continue. When a delegation is - held, the server's knowledge of the status of opens for that - client is not to be relied on, so that unless there are files - opened with the particular deny modes by clients without - delegations, the determination cannot be made until delegations - are recalled, and the operation cannot proceed until each - sufficient delegations have been returned or revoked to allow - the server to make a correct determination. - - - When a REMOVE is successfully processed, in that it will remove a - directory entry, whether that is the last reference to the - object or not, and another client holds a delegation for that object, - the delegation(s) must be recalled, the - operation cannot proceed until each such delegation is returned - or revoked. + The server MAY implement its own restrictions on removal + of a file while it is open. The server might disallow + such a REMOVE (or a removal that occurs + as part of RENAME). The conditions that influence the restrictions + on removal of a file while it is still open include: + + + Whether certain access protocols (i.e. not just + NFS) are holding the file open. + + + + + Whether particular options, access modes, or policies on the + server are enabled. + + + + + + + In all cases in which a decision is made to not allow + the file's directory entry be removed because of an + open, the error NFS4ERR_FILE_OPEN is returned. + + + + + Where the determination above cannot be made + definitively because delegations are being held, + they MUST be recalled to allow processing of the + REMOVE to continue. When a delegation is held, + the server's knowledge of the status of opens for + that client is not to be relied on, so that unless + there are files opened with the particular deny modes + by clients without delegations, the determination + cannot be made until delegations are recalled, and + the operation cannot proceed until each sufficient + delegations have been returned or revoked to allow + the server to make a correct determination. + + + In all cases in which delegations are recalled, the server - is likely to return one or more NFS4ERR_DELAY error while the - delegation(s) remains outstanding, although it may, if the - returns happen quickly, not do that. - - - If the current filehandle designates a directory for which another - client holds a directory delegation, then, unless the delegation - is such that the situation can be resolved by sending a notification, - the delegation must be recalled, and the operation cannot proceed - until the delegation is returned or revoked. Except where this - happens very quickly, one or more NFS4ERR_DELAY errors will be - returned to requests made while delegation remains outstanding. - - - When the current filehandle designates a directory for which - one or more directory delegations exist, then, when those delegations - request such notifications, NOTIFY4_REMOVE_ENTRY will be generated - as a result of this operation. Note that when a remove occurs as - a result of a RENAME, this notification will only be generated if - the removal happens as a separate operation. In the case in which - the removal is integrated with RENAME and is atomic with it, - notification of the removal is integrated with notification for the - RENAME. + is likely to return one or more NFS4ERR_DELAY errors while + delegations remain outstanding. + + + + If the current filehandle designates a directory for + which another client holds a directory delegation, + then, unless the situation can be resolved by sending + a notification, the directory delegation MUST be + recalled, and the operation MUST NOT proceed until + the delegation is returned or revoked. Except where + this happens very quickly, one or more NFS4ERR_DELAY + errors will be returned to requests made while + delegation remains outstanding. + + + + When the current filehandle designates a directory + for which one or more directory delegations + exist, then, when those delegations request + such notifications, NOTIFY4_REMOVE_ENTRY will be + generated as a result of this operation. + + + + Note that when a remove occurs as a result of a + RENAME, NOTIFY4_REMOVE_ENTRY will only be generated + if the removal happens as a separate operation. + In the case in which the removal is integrated and + atomic with RENAME, the notification of the removal + is integrated with notification for the RENAME. See + the discussion of the NOTIFY4_RENAME_ENTRY + notification in . +
Index: nfsv41_middle_op_rename.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_rename.xml,v retrieving revision 1.11 diff -u -r1.11 nfsv41_middle_op_rename.xml --- nfsv41_middle_op_rename.xml 19 Dec 2007 15:27:13 -0000 1.11 +++ nfsv41_middle_op_rename.xml 18 Apr 2008 16:55:07 -0000 @@ -17,14 +17,14 @@ source directory corresponding to the saved filehandle, as set by the SAVEFH operation, to newname in the target directory corresponding to the current filehandle. The operation is required to be atomic to the - client. Source and target directories must reside on the same + client. Source and target directories MUST reside on the same file system on the server. On success, the current filehandle will continue to be the target directory. If the target directory already contains an entry with the name, - newname, the source object must be compatible with the target: either - both are non-directories or both are directories and the target must + newname, the source object MUST be compatible with the target: either + both are non-directories or both are directories and the target MUST be empty. If compatible, the existing target is removed before the rename occurs or preferably as part of the rename and atomic with it. See @@ -41,9 +41,11 @@ will return the error, NFS4ERR_EXIST. - If oldname and newname both refer to the same file - (e.g. they might be hard links of each other), then - RENAME MUST perform no action and return NFS4_OK. + If oldname and newname both refer to the same + file (e.g. they might be hard links of each + other), then unless the file is open (see ), RENAME MUST + perform no action and return NFS4_OK. @@ -53,44 +55,47 @@ attributes were obtained atomically with respect to the rename. - If the oldname refers to a named attribute and the saved and current + If oldname refers to a named attribute and the saved and current filehandles refer to different file system objects, the server will return NFS4ERR_XDEV just as if the saved and current filehandles represented directories on different file systems. - If the oldname or newname has a length of 0 (zero), or if oldname or - newname does not obey the UTF-8 definition, the error NFS4ERR_INVAL + If oldname or newname have a length of 0 (zero), or if oldname or + newname do not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned.
- The server MAY impose restrictions on the RENAME operation such that - RENAME may not be done when the file being renamed is open or when that - open is done by particular protocols, or with particular options or access - modes. Similar restrictions may be applied when a file exists with - the target name and is open. - When RENAME is rejected because of such restrictions, the error - NFS4ERR_FILE_OPEN is returned. + The server MAY impose restrictions on the RENAME + operation such that RENAME may not be done when the + file being renamed is open or when that open is done + by particular protocols, or with particular options + or access modes. Similar restrictions may be applied + when a file exists with the target name and is open. + When RENAME is rejected because of such restrictions, + the error NFS4ERR_FILE_OPEN is returned. + - When oldname and rename refer to - the same file and that file is open is such a fashion that RENAME - would normally be rejected with NFS4ERR_FILE_OPEN, it SHOULD be - rejected and the error returned in the same way as would have been - done if oldname and newname did not refer to the same file. + When oldname and rename refer to the same file and + that file is open in a fashion such that RENAME + would normally be rejected with NFS4ERR_FILE_OPEN + if oldname and newname were different files, then + RENAME SHOULD be rejected with NFS4ERR_FILE_OPEN. + If a server does implement such restrictions and those restrictions include cases of NFSv4 opens preventing successful execution of a rename, the server needs to recall any delegations which could hide the existence of opens relevant to that decision. This is - because of the fact that when a client holds a delegation, the server - need not have accurate picture of the opens for that client, since + because when a client holds a delegation, the server + might not have an accurate account of the opens for that client, since the client may execute OPENs and CLOSEs locally. The RENAME operation - must be delayed only until a definitive result can be obtained. For + need only be delayed until a definitive result can be obtained. For example, if there are multiple delegations and one of them establishes an open whose presence would prevent the rename, given the server's semantics, NFS4ERR_FILE_OPEN may be returned to the caller as soon @@ -100,28 +105,32 @@ delegation recall being done. - If the current filehandle or the saved filehandle designates a + If the current filehandle or the saved filehandle designate a directory for which another client holds a directory delegation, - then, unless the delegation - is such that the situation can be resolved by sending a notification, - the delegation must be recalled, and the operation cannot proceed + then, unless the situation can be resolved by sending a notification, + the delegation MUST be recalled, and the operation cannot proceed until the delegation is returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be returned to requests made while delegation remains outstanding. - When the current and saved filehandles are the same and they - designate a directory for which - one or more directory delegations exist, then, when those delegations - request such notifications, a notification of type - NOTIFY4_RENAME_ENTRY will be generated - as a result of this operation. When oldname and rename refer to - the same file, it is not required that such a notification be - generated. When a file is removed because it has the same name - as the target, if that removal is done atomically with the rename, - a NOTIFY4_REMOVE_ENTRY notification will not be generated. Instead, - the deletion of the file will be reported as part of the - NOTIFY4_RENAME_ENTRY notification. + When the current and saved filehandles are the + same and they designate a directory for which one + or more directory delegations exist, then, when + those delegations request such notifications, + a notification of type NOTIFY4_RENAME_ENTRY + will be generated as a result of this operation. + When oldname and rename refer to the same file, + no notification is generated (because as states, the server + MUST take no action). When a file is removed + because it has the same name as the target, if + that removal is done atomically with the rename, + a NOTIFY4_REMOVE_ENTRY notification will not be + generated. Instead, the deletion of the file will + be reported as part of the NOTIFY4_RENAME_ENTRY + notification. + When the current and saved filehandles are not the same: @@ -147,9 +156,9 @@ - If the object being renamed has a file delegation - which is held by a client other than the one doing the RENAME, - the delegation(s) must be recalled, and the + If the object being renamed has file delegations + held by clients other than the one doing the RENAME, + the delegations MUST be recalled, and the operation cannot proceed until each such delegation is returned or revoked. Note that in the case of multiply linked files, @@ -163,7 +172,7 @@ The RENAME operation must be atomic to the client. The statement - "source and target directories must reside on the same file system + "source and target directories MUST reside on the same file system on the server" means that the fsid fields in the attributes for the directories are the same. If they reside on different file systems, Index: nfsv41_middle_op_secinfo.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_secinfo.xml,v retrieving revision 1.11 diff -u -r1.11 nfsv41_middle_op_secinfo.xml --- nfsv41_middle_op_secinfo.xml 20 Nov 2007 21:30:04 -0000 1.11 +++ nfsv41_middle_op_secinfo.xml 18 Apr 2008 16:55:07 -0000 @@ -19,7 +19,7 @@ filehandle, file name pair. SECINFO should apply the same access methodology used for LOOKUP when evaluating the name. Therefore, if the requester does not have the appropriate access - to LOOKUP the name then SECINFO must behave the same way and + to LOOKUP the name then SECINFO MUST behave the same way and return NFS4ERR_ACCESS. @@ -33,7 +33,7 @@ contain a value of AUTH_NONE, AUTH_SYS (as defined in RFC1831), or RPCSEC_GSS (as defined in RFC2203). The field flavor can - also any other security flavor registered with IANA. + also be any other security flavor registered with IANA. For the flavors AUTH_NONE and AUTH_SYS, no additional security @@ -56,7 +56,12 @@ 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. + the UTF-8 definition (assuming UTF-8 capabilities are enabled, see + ), the error NFS4ERR_INVAL will be returned. + + + See + for additional information on the use of SECINFO.
@@ -70,27 +75,70 @@ suits its policies. - As mentioned, the server's security policies will determine when - a client request receives NFS4ERR_WRONGSEC. The operations - which may receive this error are: LINK, LOOKUP, LOOKUPP, OPEN, - PUTFH, PUTPUBFH, PUTROOTFH, RESTOREFH, RENAME, and indirectly - READDIR. LINK and RENAME will only receive this error if the - security used for the operation is inappropriate for saved - filehandle. With the exception of READDIR, these operations - represent the point at which the client can instantiate a + As mentioned, the server's security + policies will determine when a client + request receives NFS4ERR_WRONGSEC. See for a list operations + which can return NFS4ERR_WRONGSEC. In addition, + when READDIR returns attributes, the rdaddr_error + () + can contain NFS4ERR_WRONGSEC. Note that CREATE and + REMOVE MUST NOT return NFS4ERR_WRONGSEC. The + rationale for CREATE is that unless the + target name exists it cannot have a separate + security policy from the parent directory, + and the security policy of the parent was + checked when its filehandle was injected into + the COMPOUND request's operations stream (for + similar reasons, an OPEN operation that creates + the target MUST NOT return NFS4ERR_WRONGSEC). If + the target name exists, while it might have a + separate security policy, that is irrelevant + because CREATE MUST return NFS4ERR_EXIST. + The rationale for REMOVE is that while that + target might have separate security policy, the + target is going to be removed, and so the the + security policy of the parent trumps that of the + object being removed. RENAME and LINK MAY return + NFS4ERR_WRONGSEC, but the NFS4ERR_WRONGSEC error + applies only to the saved filehandle (see ). Any NFS4ERR_WRONGSEC + error on the current filehandle used by LINK and + RENAME MUST be returned by the PUTFH, PUTPUBFH, + PUTROOTFH, or RESTOREFH operation that injected + the current filehandle. + + + + With the exception of LINK and RENAME, + the set of operations that can return NFS4ERR_WRONGSEC + represent the point at which the client can inject a filehandle into the "current filehandle" at the server. The filehandle is either provided by the client (PUTFH, PUTPUBFH, - PUTROOTFH) or generated as a result of a name to filehandle - translation (LOOKUP and OPEN). RESTOREFH is different because - the filehandle is a result of a previous SAVEFH. Even though - the filehandle, for RESTOREFH, might have previously passed the - server's inspection for a security match, the server will check - it again on RESTOREFH to ensure that the security policy has not - changed. + PUTROOTFH), generated as a result of a name to filehandle + translation (LOOKUP and OPEN), or generated from the saved filehandle + via RESTOREFH. As states, + a put filehandle operation followed by SAVEFH MUST NOT + return NFS4ERR_WRONGSEC. Thus the RESTOREFH operation, under + certain conditions (see ) is + permitted to return NFS4ERR_WRONGSEC so that security policies + can be honored. + + + + The READDIR operation will not directly return the + NFS4ERR_WRONGSEC error. However, if the READDIR request + included a request for attributes, it is possible that the + READDIR request's security triple did not match that of a + directory entry. If this is the case and the client has + requested the rdattr_error attribute, the server will return the + NFS4ERR_WRONGSEC error in rdattr_error for the entry. + + - If the client wants to resolve an error return of - NFS4ERR_WRONGSEC, the following will occur: + To resolve an error return of + NFS4ERR_WRONGSEC, the client does the following: @@ -100,41 +148,53 @@ same current filehandle and name as provided in the original LOOKUP or OPEN to enumerate the available security triples. + - For LINK, PUTFH, PUTROOTFH, PUTPUBFH, RENAME, and - RESTOREFH, the client will use SECINFO_NO_NAME { style = - SECINFO_STYLE4_CURRENT_FH }. The client will prefix the SECINFO_NO_NAME - operation with the appropriate PUTFH, PUTPUBFH, or - PUTROOTFH operation that provides the filehandle - originally provided by the PUTFH, PUTPUBFH, PUTROOTFH, or - RESTOREFH, or for the failed LINK or RENAME, the SAVEFH. + For the rdattr_error, the client will use + SECINFO with the same current filehandle + as provided in the original READDIR. The + name passed to SECINFO will be that of the + directory entry (as returned from READDIR) + that had the NFS4ERR_WRONGSEC error in the + rdattr_error attribute. + - NOTE: In NFSv4.0, the client was required to use SECINFO, - and had to reconstruct the parent of the original filehandle, and the component name of the original filehandle. + For PUTFH, PUTROOTFH, PUTPUBFH, + RESTOREFH, LINK, and RENAME, the client will + use SECINFO_NO_NAME { style = + SECINFO_STYLE4_CURRENT_FH }. The client + will prefix the SECINFO_NO_NAME operation + with the appropriate PUTFH, PUTPUBFH, + or PUTROOTFH operation that provides the + filehandle originally provided by the PUTFH, + PUTPUBFH, PUTROOTFH, or RESTOREFH operation. + + + + NOTE: In NFSv4.0, the client was required + to use SECINFO, and had to reconstruct the + parent of the original filehandle, and the + component name of the original filehandle. The + introduction in NFSv4.1 of SECINFO_NO_NAME + obviates the need for reconstruction. + - For LOOKUPP, the client will use SECINFO_NO_NAME { style = - SECINFO_STYLE4_PARENT } and provide the filehandle with equals the - filehandle originally provided to LOOKUPP. + For LOOKUPP, the client will + use SECINFO_NO_NAME { style = + SECINFO_STYLE4_PARENT } and provide the + filehandle which equals the filehandle + originally provided to LOOKUPP. + - The READDIR operation will not directly return the - NFS4ERR_WRONGSEC error. However, if the READDIR request - included a request for attributes, it is possible that the - READDIR request's security triple did not match that of a - directory entry. If this is the case and the client has - requested the rdattr_error attribute, the server will return the - NFS4ERR_WRONGSEC error in rdattr_error for the entry. - - - See for a discussion on - the recommendations for security flavor used by SECINFO and + the recommendations for the security flavor used by SECINFO and SECINFO_NO_NAME.
Index: nfsv41_middle_op_secinfo_no_name.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_secinfo_no_name.xml,v retrieving revision 1.13 diff -u -r1.13 nfsv41_middle_op_secinfo_no_name.xml --- nfsv41_middle_op_secinfo_no_name.xml 29 Jan 2008 08:19:32 -0000 1.13 +++ nfsv41_middle_op_secinfo_no_name.xml 18 Apr 2008 16:55:07 -0000 @@ -18,7 +18,7 @@ Like the SECINFO operation, SECINFO_NO_NAME is used by the client to obtain a list of valid RPC authentication flavors for a specific file object. Unlike SECINFO, SECINFO_NO_NAME only - works with objects are accessed by filehandle. + works with objects that are accessed by filehandle. There are two styles of SECINFO_NO_NAME, as determined by the @@ -26,7 +26,7 @@ passed, then SECINFO_NO_NAME is querying for the required security for the current filehandle. If SECINFO_STYLE4_PARENT is passed, then SECINFO_NO_NAME is querying for the required security of the - current filehandles's parent. If the style selected is SECINFO_STYLE4_PARENT, + current filehandle's parent. If the style selected is SECINFO_STYLE4_PARENT, then SECINFO should apply the same access methodology used for LOOKUPP when evaluating the traversal to the parent directory. Therefore, if the requester does not have the appropriate access @@ -34,23 +34,13 @@ way and return NFS4ERR_ACCESS. - Note that if PUTFH, PUTPUBFH, or PUTROOTFH return - NFS4ERR_WRONGSEC, this is tantamount to the server asserting - that the client will have to guess what the required security - is, because there is no way to query. Therefore, the client - must iterate through the security triples available at the - client and reattempt the PUTFH, PUTROOTFH or PUTPUBFH operation. - In the unfortunate event none of the REQUIRED security triples - are supported by the client and server, the client SHOULD try - using others that support integrity. Failing that, the client - can try using other forms (e.g. AUTH_SYS and AUTH_NONE), but - because such forms lack integrity checks, this puts the client - at risk. - - - The server implementor should pay particular attention to - - for instructions on avoiding NFS4ERR_WRONGSEC error + If PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH return + NFS4ERR_WRONGSEC, then the client resolves the + situation by sending a COMPOUND request that consists of + PUTFH, PUTPUBFH, or PUTROOTFH immediately followed by + SECINFO_NO_NAME, style SECINFO_STYLE4_CURRENT_FH. + See + for instructions on dealing with NFS4ERR_WRONGSEC error returns from PUTFH, PUTROOTFH, PUTPUBFH, or RESTOREFH. Index: nfsv41_middle_op_setattr.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_setattr.xml,v retrieving revision 1.9 diff -u -r1.9 nfsv41_middle_op_setattr.xml --- nfsv41_middle_op_setattr.xml 31 Mar 2008 23:18:57 -0000 1.9 +++ nfsv41_middle_op_setattr.xml 18 Apr 2008 16:55:07 -0000 @@ -28,15 +28,15 @@ as would have been the case had the area in question been specified as the target of WRITE, for the purpose of checking conflicts with byte-range locks, for those cases in which a server is implementing mandatory - byte-range locking behavior. A valid stateid should always be specified. + byte-range locking behavior. A valid stateid SHOULD always be specified. When the file size attribute is not set, the special stateid - consisting of all bits zero should be passed. + consisting of all bits zero MAY be passed. On either success or failure of the operation, the server will return the attrsset bitmask to represent what (if any) attributes were successfully set. The attrsset in the response is a subset of the - bitmap4 that is part of the obj_attributes in the argument. + attrmask field of the obj_attributes field in the argument. On success, the current filehandle retains its value. @@ -45,29 +45,36 @@
If the request specifies the owner attribute to be set, the server - should allow the operation to succeed if the current owner of the + SHOULD allow the operation to succeed if the current owner of the object matches the value specified in the request. Some servers may be implemented in a way as to prohibit the setting of the owner attribute unless the requester has privilege to do so. If the server is lenient in this one case of matching owner values, the client implementation may be simplified in cases of creation of an object + (e.g. an exclusive create via OPEN) followed by a SETATTR. - The file size attribute is used to request changes to the size of a - file. A value of 0 (zero) causes the file to be truncated, a value - less than the current size of the file causes data from new size to - the end of the file to be discarded, and a size greater than the - current size of the file causes logically zeroed data bytes to be - added to the end of the file. Servers are free to implement this - using holes or actual zero data bytes. Clients should not make any - assumptions regarding a server's implementation of this feature, - beyond that the bytes returned will be zeroed. Servers must support - extending the file size via SETATTR. - - - SETATTR is not guaranteed atomic. A failed SETATTR may partially - change a file's attributes. + The file size attribute is used to request changes + to the size of a file. A value of zero causes the + file to be truncated, a value less than the current + size of the file causes data from new size to the + end of the file to be discarded, and a size greater + than the current size of the file causes logically + zeroed data bytes to be added to the end of the + file. Servers are free to implement this using + unallocate bytes (holes) or allocated data bytes + set to zero. Clients should not make any assumptions + regarding a server's implementation of this feature, + beyond that the bytes in affected region returned by + READ will be zeroed. Servers MUST support extending + the file size via SETATTR. + + + + SETATTR is not guaranteed to be atomic. A failed SETATTR may partially + change a file's attributes, hence the reason why the reply always + includes the status and the list of attributes that were set. If the object whose attributes are being changed has a file delegation @@ -84,7 +91,7 @@ If the object whose attributes are being set is a directory and another client holds a directory delegation for that - directory, then asynchronous notifications will be generated + directory, then if enabled, asynchronous notifications will be generated when the set of attributes changed has a non-null intersection with the set of attributes for which notification is requested. Notifications of type NOTIFY4_CHANGE_DIR_ATTRS will be sent to @@ -98,13 +105,15 @@ when the set of attributes changed has a non-null intersection with the set of attributes for which notification is requested. Notifications of type NOTIFY4_CHANGE_CHILD_ATTRS will be sent to - the appropriate client(s), but the SETATTR is not delayed by + the appropriate clients, but the SETATTR is not delayed by waiting for these notifications to be sent. - Changing the size of a file with SETATTR indirectly changes the - time_modify. A client must account for this as size changes can result - in data deletion. + Changing the size of a file with SETATTR indirectly + changes the time_modify and change attributes. + A client must account for this as size changes can + result in data deletion. + The attributes time_access_set and time_modify_set are write-only @@ -117,7 +126,7 @@ If server and client times differ, programs that compare client time - to file times can break. A time maintenance protocol should be used to + to file times can break. A time synchronization protocol should be used to limit client/server time skew. @@ -129,19 +138,19 @@ based on stale information, delays between checking of the guard condition and the setting of the attributes have the potential to compromise this function, as would the corresponding delay in the - NFSv4 emulation. Therefore, NFSv4.1 servers should take + NFSv4 emulation. Therefore, NFSv4.1 servers SHOULD take care to avoid such delays, to the degree possible, when executing such a request. If the server does not support an attribute as requested by the - client, the server should return NFS4ERR_ATTRNOTSUPP. + client, the server SHOULD return NFS4ERR_ATTRNOTSUPP. A mask of the attributes actually set is returned by SETATTR in all - cases. That mask must not include attributes bits not requested to be - set by the client, and must be equal to the mask of attributes - requested to be set only if the SETATTR completes without error. + cases. That mask MUST NOT include attributes bits not requested to be + set by the client. If the attribute masks in the request and + reply are equal, the the status field in the reply MUST be NFS4_OK.
Index: nfsv41_middle_op_verify.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_verify.xml,v retrieving revision 1.7 diff -u -r1.7 nfsv41_middle_op_verify.xml --- nfsv41_middle_op_verify.xml 29 Jan 2008 08:19:32 -0000 1.7 +++ nfsv41_middle_op_verify.xml 18 Apr 2008 16:55:07 -0000 @@ -13,19 +13,19 @@
- The VERIFY operation is used to verify that attributes have a value + The VERIFY operation is used to verify that attributes have the value assumed by the client before proceeding with following operations in - the compound request. If any of the attributes do not match then the + the COMPOUND request. If any of the attributes do not match then the error NFS4ERR_NOT_SAME must be returned. The current filehandle retains its value after successful completion of the operation.
- One possible use of the VERIFY operation is the following compound - sequence. With this the client is attempting to verify that the file + One possible use of the VERIFY operation is the following series + of operations. With this the client is attempting to verify that the file being removed will match what the client expects to be removed. This - sequence can help prevent the unintended deletion of a file. + series can help prevent the unintended deletion of a file.
PUTFH (directory filehandle) @@ -35,7 +35,7 @@ REMOVE (file name)
- This sequence does not prevent a second client from removing and + This series does not prevent a second client from removing and creating a new file in the middle of this sequence but it does help avoid the unintended result. @@ -46,7 +46,7 @@ client. - When the attribute rdattr_error or any write-only attribute (e.g. + When the attribute rdattr_error or any set-only attribute (e.g. time_modify_set) is specified, the error NFS4ERR_INVAL is returned to the client. Index: nfsv41_middle_op_write.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_write.xml,v retrieving revision 1.15 diff -u -r1.15 nfsv41_middle_op_write.xml --- nfsv41_middle_op_write.xml 31 Mar 2008 23:18:57 -0000 1.15 +++ nfsv41_middle_op_write.xml 18 Apr 2008 16:55:07 -0000 @@ -20,18 +20,17 @@ file. The count, as encoded as part of the opaque data parameter, represents the number of bytes of data that are to be written. If the count is 0 (zero), the WRITE will succeed and return a count of 0 - (zero) subject to permissions checking. The server may choose to + (zero) subject to permissions checking. The server MAY write fewer bytes than requested by the client. - Part of the write request is a specification of how the write is to be - performed. The client specifies with the stable parameter the method + The client specifies with the stable parameter the method of how the data is to be processed by the server. If stable is - FILE_SYNC4, the server must commit the data written plus all + FILE_SYNC4, the server MUST commit the data written plus all file system metadata to stable storage before returning results. This corresponds to the NFSv2 protocol semantics. Any other behavior constitutes a protocol violation. If stable is DATA_SYNC4, - then the server must commit all of the data to stable storage and + then the server MUST commit all of the data to stable storage and enough of the metadata to retrieve the data before returning. The server implementor is free to implement DATA_SYNC4 in the same fashion as FILE_SYNC4, but with a possible performance drop. If stable is @@ -40,14 +39,14 @@ reply to the client. There is no guarantee whether or when any uncommitted data will subsequently be committed to stable storage. The only guarantees made by the server are that it will not destroy any - data without changing the value of verf and that it will not commit + data without changing the value of writeverf and that it will not commit the data and metadata at a level less than that requested by the client. Except when special stateids are used, the stateid value for a WRITE request represents a value returned from - a previous byte-range lock or share reservation request or the stateid + a previous byte-range LOCK or OPEN request or the stateid associated with a delegation. The stateid identifies the associated owners if any and is used by the server to verify that the associated locks are still @@ -61,25 +60,58 @@ The server also returns an indication of the level of commitment of - the data and metadata via committed. If the server committed all data - and metadata to stable storage, committed should be set to - FILE_SYNC4. If the level of commitment was at least as strong as - DATA_SYNC4, then committed should be set to DATA_SYNC4. Otherwise, - committed must be returned as UNSTABLE4. If stable was FILE4_SYNC, - then committed must also be FILE_SYNC4: anything else constitutes a - protocol violation. If stable was DATA_SYNC4, then committed may be - FILE_SYNC4 or DATA_SYNC4: anything else constitutes a protocol - violation. If stable was UNSTABLE4, then committed may be either - FILE_SYNC4, DATA_SYNC4, or UNSTABLE4. - - - The final portion of the result is the write verifier. The write - verifier is a cookie that the client can use to determine whether the - server has changed instance (boot) state between a call to WRITE and a - subsequent call to either WRITE or COMMIT. This cookie must be - consistent during a single instance of the NFSv4.1 protocol - service and must be unique between instances of the NFSv4.1 - protocol server, where uncommitted data may be lost. + the data and metadata via committed. + Per , + + + The server MAY commit the data at a stronger level + than requested. + + + + + The server MUST commit the data at a level at + least as high as that committed. + + + + + + + + + + Valid combinations of the fields stable in the request and committed in + the reply. + + + + stable + + committed + + UNSTABLE4 FILE_SYNC4, DATA_SYNC4, UNSTABLE4 + + DATA_SYNC4 FILE_SYNC4, DATA_SYNC4 + + FILE_SYNC4 FILE_SYNC4 + + + + + The final portion of the result is the field + writeverf. This field is the write verifier and is a + cookie that the client can use to determine whether + a server has changed instance state (e.g. server + restart) between a call to WRITE and a subsequent + call to either WRITE or COMMIT. This cookie MUST be + unchanged during a single instance of the NFSv4.1 + server and MUST be unique between instances of the + NFSv4.1 server. If the cookie changes, then the + client MUST assume that any data written with an + UNSTABLE4 value for committed and an old writeverf in the reply + has been lost and will need to be recovered. + If a client writes data to the server with the stable argument set to @@ -95,8 +127,8 @@ the WRITE to be serviced subject to mandatory file locks or the current share deny modes for the file. For a WRITE with a stateid value of all bits 1, the server MUST NOT allow the WRITE operation to - bypass locking checks at the server and are treated exactly the same - as if a stateid of all bits 0 were used. + bypass locking checks at the server and otherwise is + treated as if a stateid of all bits 0 were used. On success, the current filehandle retains its value. @@ -105,23 +137,23 @@
It is possible for the server to write fewer bytes of data than - requested by the client. In this case, the server should not return + requested by the client. In this case, the server SHOULD NOT return an error unless no data was written at all. If the server writes less - than the number of bytes specified, the client should send another + than the number of bytes specified, the client will need to send another WRITE to write the remaining data. - It is assumed that the act of writing data to a file will cause the - time_modified of the file to be updated. However, the time_modified - of the file should not be changed unless the contents of the file are - changed. Thus, a WRITE request with count set to 0 should not cause - the time_modified of the file to be updated. + It is assumed that the act of writing data to + a file will cause the time_modified and change + attributes of the file to be updated. However, + these attributes SHOULD NOT be changed + unless the contents of the file are changed. Thus, + a WRITE request with count set to 0 SHOULD NOT cause + the time_modified and change attributes of the file to be updated. + - The definition of stable storage has been historically a point of - contention. The following expected properties of stable storage may - help in resolving design sends in the implementation. Stable storage - is persistent storage that survives: + Stable storage is persistent storage that survives: @@ -141,51 +173,68 @@ itself. - The verifier is defined to allow a client to detect different - instances of an NFSv4.1 protocol server over which cached, - uncommitted data may be lost. In the most likely case, the verifier - allows the client to detect server restarts. This information is - required so that the client can safely determine whether the server - could have lost cached data. If the server fails unexpectedly and the - client has uncommitted data from previous WRITE requests (done with - the stable argument set to UNSTABLE4 and in which the result committed - was returned as UNSTABLE4 as well) it may not have flushed cached data - to stable storage. The burden of recovery is on the client and the - client will need to retransmit the data to the server. - - - A suggested verifier would be to use the time that the server - was last started (if restarting the - server results in lost buffers). + The verifier is defined to allow a client to detect + different instances of an NFSv4.1 protocol server + over which cached, uncommitted data may be lost. In + the most likely case, the verifier allows the client + to detect server restarts. This information is + required so that the client can safely determine + whether the server could have lost cached data. + If the server fails unexpectedly and the client has + uncommitted data from previous WRITE requests (done + with the stable argument set to UNSTABLE4 and in + which the result committed was returned as UNSTABLE4 + as well) the server might not have flushed cached + data to stable storage. The burden of recovery is + on the client and the client will need to retransmit + the data to the server. + + + + A suggested verifier would be to use the time that + the server was last started (if restarting the server + results in lost buffers). + - The committed field in the results allows the client to do more + The reply's committed field allows the client to do more effective caching. If the server is committing all WRITE requests to - stable storage, then it should return with committed set to FILE_SYNC4, + stable storage, then it SHOULD return with committed set to FILE_SYNC4, regardless of the value of the stable field in the arguments. A server that uses an NVRAM accelerator may choose to implement this policy. The client can use this to increase the effectiveness of the cache by discarding cached data that has already been committed on the server. - Some implementations may return NFS4ERR_NOSPC instead of NFS4ERR_DQUOT - when a user's quota is exceeded. In the case that the current - filehandle is of type NF4DIR, the server will return NFS4ERR_ISDIR. - If the current file is a symbolic link, the error NFS4ERR_SYMLINK - will be returned. Otherwise, if the current filehandle does not - designate an ordinary file, the server will return NFS4ERR_WRONG_TYPE. - - - If mandatory file locking is on for the file, and corresponding byte-range - of the data to be written file is read or write locked by an owner - that is not associated with the stateid, the server will return - NFS4ERR_LOCKED. If so, the client must check if the owner - corresponding to the stateid used with the WRITE operation has a - conflicting read lock that overlaps with the region that was to be - written. If the stateid's owner has no conflicting read lock, then the - client should try to get the appropriate write byte-range lock via the - LOCK operation before re-attempting the WRITE. When the WRITE - completes, the client should release the byte-range lock via LOCKU. + Some implementations may return NFS4ERR_NOSPC instead + of NFS4ERR_DQUOT when a user's quota is exceeded. + + + + In the case that the current filehandle is of + type NF4DIR, the server will return NFS4ERR_ISDIR. + If the current file is a symbolic link, the error + NFS4ERR_SYMLINK will be returned. Otherwise, if the + current filehandle does not designate an ordinary + file, the server will return NFS4ERR_WRONG_TYPE. + + + + If mandatory file locking is in effect for the file, + and the corresponding byte-range of the data to + be written to the file is read or write locked by + an owner that is not associated with the stateid, + the server MUST return NFS4ERR_LOCKED. If so, + the client MUST check if the owner corresponding + to the stateid used with the WRITE operation has a + conflicting read lock that overlaps with the region + that was to be written. If the stateid's owner has + no conflicting read lock, then the client SHOULD try + to get the appropriate write byte-range lock via the + LOCK operation before re-attempting the WRITE. When + the WRITE completes, the client SHOULD release the + byte-range lock via LOCKU. + If the stateid's owner had a conflicting read lock, then the client @@ -202,7 +251,7 @@ If one or more other clients have delegations for the file being - written, those delegations must be recalled, and the + written, those delegations MUST be recalled, and the operation cannot proceed until those delegations are returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be Index: nfsv41_middle_state_mgmt.xml =================================================================== RCS file: /cvs/stdk/NFSv41/nfsv41_middle_state_mgmt.xml,v retrieving revision 1.33 diff -u -r1.33 nfsv41_middle_state_mgmt.xml --- nfsv41_middle_state_mgmt.xml 31 Mar 2008 23:18:57 -0000 1.33 +++ nfsv41_middle_state_mgmt.xml 18 Apr 2008 16:55:08 -0000 @@ -105,8 +105,8 @@
- With the exception of special stateids, to be discussed - later, each stateid + With the exception of special stateids (see ), + each stateid represents locking objects of one of a set of types defined by the NFSv4.1 protocol. Note that in all these cases, where we speak of guarantee, it is understood there are @@ -175,8 +175,9 @@ Stateids are divided into two fields, a 96-bit "other" field identifying the specific set of locks and a 32-bit "seqid" sequence value. - Except in the case of special stateids, to be - discussed below, a particular value of the + Except in the case of special stateids + (see ), + a particular value of the "other" field denotes a set of locks of the same type (for example byte-range locks, opens, delegations, or layouts), @@ -424,7 +425,7 @@ the appropriate error returned when necessary. Special and non-special stateids are handled separately. (See for a discussion of special - stateids). + stateids.) Note that stateids are implicitly qualified by the current client