idnits 2.17.1 draft-gruenbacher-nfsv4-file-masks-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 300. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2006) is 6457 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 254 looks like a reference -- Missing reference section? '2' on line 258 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 A. Gruenbacher 3 Internet-Draft SUSE Labs, Novell 4 Expires: February 2, 2007 J. Fields 5 CITI 6 August 2006 8 NFSv4 file_masks Attribute 9 draft-gruenbacher-nfsv4-file-masks-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 2, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Some NFSv4 servers allow a mode SETATTR to restore ACL permissions 43 which were removed by a previous mode SETATTR. This allows servers 44 to handle mode SETATTRs without destroying the information in ACLs. 45 However, these temporarily masked permissions are not exposed to 46 clients. This proposal adds an optional new file attribute, 47 file_masks, which can be used by clients to see these temporarily 48 masked permissions. 50 The operations of the NFSv4 mode and ACL attributes are unchanged, 51 but extra information is made available to clients to aid, for 52 example, in archiving of data without losing permissions information. 54 1. Problem Statement 56 The NFSv4 specification [1] defines both an ACL and a mode file 57 attribute. 59 The NFSv4 mode attribute corresponds to the file mode on POSIX 60 systems. POSIX requires that after the file mode is set, no process 61 is granted more permissions than allowed by the file mode itself 62 (definition of File Access Permissions [2]). 64 Therefore a server that wishes to implement the NFSv4 mode attribute 65 in a POSIX compliant way must, after a mode SETATTR, restrict the ACL 66 to meet the above requirement. 68 In the process, much or all of the information present in the 69 original ACL can be lost. This is often undesirable. Traditional 70 POSIX filesystems have the property that restoring a mode to a 71 previous value will restore all permissions to the previous value, 72 and some applications may depend on this property. 74 Therefore, many filesystems that support both ACLs and mode bits 75 implement them in such a way that setting a more restrictive mode and 76 then restoring the original mode will also restore as much of the 77 original ACL as possible. 79 Filesystems do this by storing a "mask" which is independent from the 80 rest of the ACL, and modifying only the mask on chmod(). This allows 81 the filesystem to enforce restricted permissions without having to 82 modify the original ACL. 84 A server exporting such a filesystem can return to NFSv4 clients an 85 ACL that has the mask already applied (and hence represents the 86 effective permissions on the file). There are advantages to also 87 allowing the client access to the mask and the unmasked ACL: 88 1. The client is then able to see and manipulate all of the server's 89 permission state beyond the effective permissions. Examples 90 where this additional state would be useful are permission- 91 preserving copy and backup/restore. 92 2. Restoring the original mode may not always completely restore the 93 original ACL, because the ACL may grant mask flags (such as 94 WRITE_OWNER) which go beyond the permissions covered by the mode 95 attribute, and such permissions are usually turned off by a mode 96 SETATTR. In this situation, the ability to explicitly set a 97 larger mask allows the client to restore the original ACL in its 98 entirety if desired. 100 In most situations, however, an ACL representing the effective 101 permissions on a file is still more useful. Also, clients should not 102 be required to have knowledge of the server's masking behavior. For 103 that reason, we must ensure that the NFSv4 ACL attribute continues to 104 function exactly as described in RFC 3530, and we must ensure that 105 any additional protocol is entirely optional. 107 2. File Masks Proposal 109 We propose to add an optional file_masks attribute to NFSv4. This 110 attribute consists of a file owner, group, and other mask, each 111 containing ACE access masks. The file masks correspond to the owner, 112 group, and other permission bits in the mode attribute. 114 struct file_masks { 115 acemask4 owner_mask; 116 acemask4 group_mask; 117 acemask4 other_mask; 118 }; 120 The file_masks attribute has the following properties: 121 1. After an _ACL_ SETATTR: 122 1. The mask flags that principals are granted are determined by 123 _ACL_ alone. 124 2. An ACL GETATTR returns _ACL_. 125 3. Each of the the file masks are set to a superset of the mask 126 flags granted to all principals with which the file mask 127 corresponds. This guarantees that the file masks will have 128 no effect on the permission check algorithm, as required by 129 Paragraph 1.1. 130 4. The mode attribute is set so that it reflects _ACL_. 131 2. After a _mode_ SETATTR: 132 1. No principal shall be granted more than its corresponding 133 file permission bits in _mode_. 134 2. A mode GETATTR returns _mode_. 135 3. Each of the file masks is updated based on its corresponding 136 file permission bits in _mode_: For each file mask, if the 137 corresponding Read, Write, and Execute permission is set, set 138 all mask flags that are equivalent to or a subset of that 139 permission, and clear all others. Set all mask flags that 140 are always allowed under POSIX. (With the file masks updated 141 based on _mode_, Paragraph 2.1 is equivalent to 142 Paragraph 3.1.) 144 4. An ACL GETATTR should return the ACL that results from 145 applying the updated file masks to it. (This is equivalent 146 to applying _mode _ to the ACL, which must also first convert 147 _mode_ to the appropriate mask flags.) 148 3. After a _file_masks_ SETATTR: 149 1. No principal shall be allowed more than its corresponding 150 file mask in _file_masks_. 151 2. A file_masks GETATTR returns _file_masks_. 152 3. The file permission bits in the file mode are updated based 153 on their corresponding file masks in _file_masks_: For each 154 set of permissions in the file mode, set those permissions 155 for which the corresponding file mask contains mask flags 156 that are equivalent to or a subset of the permissions, and 157 clear all others. 158 4. An ACL GETATTR shall return the ACL that results from 159 applying _file_masks_ to it. 160 4. A GETATTR for both _file_masks_ and _ACL_ shall return the file 161 masks, together with the unmodified ACL. 162 5. A SETATTR of mode, ACL, and/or file_masks shall process the 163 attributes in the order of mode, ACL, file_masks. 164 This proposal allows servers to implement the masking behavior 165 described in Section 1 while avoiding the disadvantages discussed 166 there. 168 3. Access Check Algorithm 170 When separately storing the unmodified ACL attribute and the file 171 masks on the server, the permission check algorithm needs to take 172 both the ACL and the file masks into account. This can be achieved 173 by separately checking if both the ACL and the file masks permit the 174 requested access. 176 The file masks can have two different meanings during access checks: 177 they can be used to further limit the mask flags that the ACL allows, 178 or they can limit the mask flags that the ACL allows, while at the 179 same time defining the permissions granted to OWNER@, GROUP@, and 180 EVERYONE@. 182 Both variants correspond to different ways of applying file masks to 183 an ACL. The latter variant corresponds to having the file masks 184 "write through" to OWNER@, GROUP@, and EVERYONE@ ACL entries, and 185 replace their existing mask flags. 187 The following two sections define access check algorithms that can be 188 used in these two cases. 190 3.1. Access Check Algorithm Without Write-Through 192 1. If the principal does not match the file owner, continue with the 193 next paragraph. Otherwise, if the requested mask flags exceed 194 the owner mask, deny access. Otherwise, use the NFSv4 permission 195 check algorithm to determine access. 196 2. If the principal is not a member in the owning group and none of 197 the entries in the ACL with who values other than EVERYONE@ match 198 the principal, continue with the next paragraph. Otherwise, if 199 the requested mask flags exceed the group mask, deny access. 200 Otherwise, use the NFSv4 permission check algorithm to determine 201 access. 202 3. If the requested mask flags exceed the other mask, deny access. 203 Otherwise, use the NFSv4 permission check algorithm to determine 204 access. 206 3.2. Access Check Algorithm With Write-Through 208 1. If the principal does not match the file owner, continue with the 209 next paragraph. Otherwise, if the requested mask flags exceed 210 the owner mask, deny access. Otherwise, allow access. 211 2. If the principal is not a member in the owning group, continue 212 with the next paragraph. Otherwise, if the requested mask flags 213 exceed the group mask, deny access. Otherwise, allow access. 214 3. If none of the entries in the ACL with who values other then 215 EVERYONE@ match the principal, continue with the next paragraph. 216 Otherwise, if the requested mask flags exceed the group mask, 217 deny access. Otherwise, use the NFSv4 permission check algorithm 218 to determine access. 219 4. If the requested mask flags exceed the other mask, deny access. 220 Otherwise, allow access. 222 4. Discussion 224 The proposed solution meets the following goals: 225 o Servers and clients that do not implement the _file_masks_ 226 attribute will be unaffected, and will not observe any changes. 227 o The described approach does not preclude any alternative solutions 228 to the problems described that may exist. 229 o Setting the mode attribute to a permissive value will grant as 230 many permissions in the ACL as the mode allows. Sequences of mode 231 SETATTR are equivalent to only performing the last mode SETATTR. 232 o The complete permission information can be preserved when copying 233 files, including permissions that are currently disabled. 234 o Clients that care can implement ACL editors that take both the ACL 235 and the file masks into account. 236 The following disadvantages are known: 238 o The file masks will not be preserved across sequences of ACL 239 GETATTR / ACL SETATTR. 240 o Independently checking if an access is granted by the ACL and by 241 the file masks can lead to permissions that cannot be represented 242 as an ACL, as when mode 0600 is applied to ACL "GROUP@:READ_DATA:: 243 ALLOW": in this case, only owners who are also in the owning group 244 would be granted READ_DATA access. Granting permissions that 245 cannot be represented as an ACL can be avoided by applying the 246 group mask to all ACL entries with who values other than OWNER@ 247 and EVERYONE@ during access checks. 248 o The proposal requires the _file_masks_ attribute to be added to 249 the protocol, and its behavior specified, which would make a long 250 RFC even longer. 252 5. References 254 [1] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, 255 C., Eisler, M., and D. Noveck, "Network File System (NFS) 256 version 4 Protocol", RFC 3530, April 2003. 258 [2] Institute of Electrical and Electronics Engineers, "Information 259 Technology - Portable Operating System Interface (POSIX) - Base 260 Definitions", IEEE Standard 1003.1, December 2004. 262 Authors' Addresses 264 Andreas Gruenbacher 265 Novell / SUSE Labs 266 Maxfeldstrasse 5 267 90409 Nuremberg 269 Email: agruen@suse.de 271 J. Bruce Fields 272 U. of Michigan, Center for Informaton Technology Integration (CITI) 273 535 West William 274 Ann Arbor, Michigan 276 Email: bfields@citi.umich.edu 278 Intellectual Property Statement 280 The IETF takes no position regarding the validity or scope of any 281 Intellectual Property Rights or other rights that might be claimed to 282 pertain to the implementation or use of the technology described in 283 this document or the extent to which any license under such rights 284 might or might not be available; nor does it represent that it has 285 made any independent effort to identify any such rights. Information 286 on the procedures with respect to rights in RFC documents can be 287 found in BCP 78 and BCP 79. 289 Copies of IPR disclosures made to the IETF Secretariat and any 290 assurances of licenses to be made available, or the result of an 291 attempt made to obtain a general license or permission for the use of 292 such proprietary rights by implementers or users of this 293 specification can be obtained from the IETF on-line IPR repository at 294 http://www.ietf.org/ipr. 296 The IETF invites any interested party to bring to its attention any 297 copyrights, patents or patent applications, or other proprietary 298 rights that may cover technology that may be required to implement 299 this standard. Please address the information to the IETF at 300 ietf-ipr@ietf.org. 302 Disclaimer of Validity 304 This document and the information contained herein are provided on an 305 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 306 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 307 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 308 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 309 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 310 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 312 Copyright Statement 314 Copyright (C) The Internet Society (2006). This document is subject 315 to the rights, licenses and restrictions contained in BCP 78, and 316 except as set forth therein, the authors retain all their rights. 318 Acknowledgment 320 Funding for the RFC Editor function is currently provided by the 321 Internet Society.