Network File System Version 4 A. Gruenbacher Internet-Draft SUSE Labs, Novell Expires: February 2, 2007 J. Fields CITI August 2006 NFSv4 file_masks Attribute draft-gruenbacher-nfsv4-file-masks-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 2, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Some NFSv4 servers allow a mode SETATTR to restore ACL permissions which were removed by a previous mode SETATTR. This allows servers to handle mode SETATTRs without destroying the information in ACLs. However, these temporarily masked permissions are not exposed to clients. This proposal adds an optional new file attribute, file_masks, which can be used by clients to see these temporarily masked permissions. Gruenbacher & Fields Expires February 2, 2007 [Page 1] Internet-Draft NFSv4 file_masks Attribute August 2006 The operations of the NFSv4 mode and ACL attributes are unchanged, but extra information is made available to clients to aid, for example, in archiving of data without losing permissions information. 1. Problem Statement The NFSv4 specification [1] defines both an ACL and a mode file attribute. The NFSv4 mode attribute corresponds to the file mode on POSIX systems. POSIX requires that after the file mode is set, no process is granted more permissions than allowed by the file mode itself (definition of File Access Permissions [2]). Therefore a server that wishes to implement the NFSv4 mode attribute in a POSIX compliant way must, after a mode SETATTR, restrict the ACL to meet the above requirement. In the process, much or all of the information present in the original ACL can be lost. This is often undesirable. Traditional POSIX filesystems have the property that restoring a mode to a previous value will restore all permissions to the previous value, and some applications may depend on this property. Therefore, many filesystems that support both ACLs and mode bits implement them in such a way that setting a more restrictive mode and then restoring the original mode will also restore as much of the original ACL as possible. Filesystems do this by storing a "mask" which is independent from the rest of the ACL, and modifying only the mask on chmod(). This allows the filesystem to enforce restricted permissions without having to modify the original ACL. A server exporting such a filesystem can return to NFSv4 clients an ACL that has the mask already applied (and hence represents the effective permissions on the file). There are advantages to also allowing the client access to the mask and the unmasked ACL: 1. The client is then able to see and manipulate all of the server's permission state beyond the effective permissions. Examples where this additional state would be useful are permission- preserving copy and backup/restore. 2. Restoring the original mode may not always completely restore the original ACL, because the ACL may grant mask flags (such as WRITE_OWNER) which go beyond the permissions covered by the mode attribute, and such permissions are usually turned off by a mode SETATTR. In this situation, the ability to explicitly set a Gruenbacher & Fields Expires February 2, 2007 [Page 2] Internet-Draft NFSv4 file_masks Attribute August 2006 larger mask allows the client to restore the original ACL in its entirety if desired. In most situations, however, an ACL representing the effective permissions on a file is still more useful. Also, clients should not be required to have knowledge of the server's masking behavior. For that reason, we must ensure that the NFSv4 ACL attribute continues to function exactly as described in RFC 3530, and we must ensure that any additional protocol is entirely optional. 2. File Masks Proposal We propose to add an optional file_masks attribute to NFSv4. This attribute consists of a file owner, group, and other mask, each containing ACE access masks. The file masks correspond to the owner, group, and other permission bits in the mode attribute. struct file_masks { acemask4 owner_mask; acemask4 group_mask; acemask4 other_mask; }; The file_masks attribute has the following properties: 1. After an _ACL_ SETATTR: 1. The mask flags that principals are granted are determined by _ACL_ alone. 2. An ACL GETATTR returns _ACL_. 3. Each of the the file masks are set to a superset of the mask flags granted to all principals with which the file mask corresponds. This guarantees that the file masks will have no effect on the permission check algorithm, as required by Paragraph 1.1. 4. The mode attribute is set so that it reflects _ACL_. 2. After a _mode_ SETATTR: 1. No principal shall be granted more than its corresponding file permission bits in _mode_. 2. A mode GETATTR returns _mode_. 3. Each of the file masks is updated based on its corresponding file permission bits in _mode_: For each file mask, if the corresponding Read, Write, and Execute permission is set, set all mask flags that are equivalent to or a subset of that permission, and clear all others. Set all mask flags that are always allowed under POSIX. (With the file masks updated based on _mode_, Paragraph 2.1 is equivalent to Paragraph 3.1.) Gruenbacher & Fields Expires February 2, 2007 [Page 3] Internet-Draft NFSv4 file_masks Attribute August 2006 4. An ACL GETATTR should return the ACL that results from applying the updated file masks to it. (This is equivalent to applying _mode _ to the ACL, which must also first convert _mode_ to the appropriate mask flags.) 3. After a _file_masks_ SETATTR: 1. No principal shall be allowed more than its corresponding file mask in _file_masks_. 2. A file_masks GETATTR returns _file_masks_. 3. The file permission bits in the file mode are updated based on their corresponding file masks in _file_masks_: For each set of permissions in the file mode, set those permissions for which the corresponding file mask contains mask flags that are equivalent to or a subset of the permissions, and clear all others. 4. An ACL GETATTR shall return the ACL that results from applying _file_masks_ to it. 4. A GETATTR for both _file_masks_ and _ACL_ shall return the file masks, together with the unmodified ACL. 5. A SETATTR of mode, ACL, and/or file_masks shall process the attributes in the order of mode, ACL, file_masks. This proposal allows servers to implement the masking behavior described in Section 1 while avoiding the disadvantages discussed there. 3. Access Check Algorithm When separately storing the unmodified ACL attribute and the file masks on the server, the permission check algorithm needs to take both the ACL and the file masks into account. This can be achieved by separately checking if both the ACL and the file masks permit the requested access. The file masks can have two different meanings during access checks: they can be used to further limit the mask flags that the ACL allows, or they can limit the mask flags that the ACL allows, while at the same time defining the permissions granted to OWNER@, GROUP@, and EVERYONE@. Both variants correspond to different ways of applying file masks to an ACL. The latter variant corresponds to having the file masks "write through" to OWNER@, GROUP@, and EVERYONE@ ACL entries, and replace their existing mask flags. The following two sections define access check algorithms that can be used in these two cases. Gruenbacher & Fields Expires February 2, 2007 [Page 4] Internet-Draft NFSv4 file_masks Attribute August 2006 3.1. Access Check Algorithm Without Write-Through 1. If the principal does not match the file owner, continue with the next paragraph. Otherwise, if the requested mask flags exceed the owner mask, deny access. Otherwise, use the NFSv4 permission check algorithm to determine access. 2. If the principal is not a member in the owning group and none of the entries in the ACL with who values other than EVERYONE@ match the principal, continue with the next paragraph. Otherwise, if the requested mask flags exceed the group mask, deny access. Otherwise, use the NFSv4 permission check algorithm to determine access. 3. If the requested mask flags exceed the other mask, deny access. Otherwise, use the NFSv4 permission check algorithm to determine access. 3.2. Access Check Algorithm With Write-Through 1. If the principal does not match the file owner, continue with the next paragraph. Otherwise, if the requested mask flags exceed the owner mask, deny access. Otherwise, allow access. 2. If the principal is not a member in the owning group, continue with the next paragraph. Otherwise, if the requested mask flags exceed the group mask, deny access. Otherwise, allow access. 3. If none of the entries in the ACL with who values other then EVERYONE@ match the principal, continue with the next paragraph. Otherwise, if the requested mask flags exceed the group mask, deny access. Otherwise, use the NFSv4 permission check algorithm to determine access. 4. If the requested mask flags exceed the other mask, deny access. Otherwise, allow access. 4. Discussion The proposed solution meets the following goals: o Servers and clients that do not implement the _file_masks_ attribute will be unaffected, and will not observe any changes. o The described approach does not preclude any alternative solutions to the problems described that may exist. o Setting the mode attribute to a permissive value will grant as many permissions in the ACL as the mode allows. Sequences of mode SETATTR are equivalent to only performing the last mode SETATTR. o The complete permission information can be preserved when copying files, including permissions that are currently disabled. o Clients that care can implement ACL editors that take both the ACL and the file masks into account. The following disadvantages are known: Gruenbacher & Fields Expires February 2, 2007 [Page 5] Internet-Draft NFSv4 file_masks Attribute August 2006 o The file masks will not be preserved across sequences of ACL GETATTR / ACL SETATTR. o Independently checking if an access is granted by the ACL and by the file masks can lead to permissions that cannot be represented as an ACL, as when mode 0600 is applied to ACL "GROUP@:READ_DATA:: ALLOW": in this case, only owners who are also in the owning group would be granted READ_DATA access. Granting permissions that cannot be represented as an ACL can be avoided by applying the group mask to all ACL entries with who values other than OWNER@ and EVERYONE@ during access checks. o The proposal requires the _file_masks_ attribute to be added to the protocol, and its behavior specified, which would make a long RFC even longer. 5. References [1] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003. [2] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Base Definitions", IEEE Standard 1003.1, December 2004. Gruenbacher & Fields Expires February 2, 2007 [Page 6] Internet-Draft NFSv4 file_masks Attribute August 2006 Authors' Addresses Andreas Gruenbacher Novell / SUSE Labs Maxfeldstrasse 5 90409 Nuremberg Email: agruen@suse.de J. Bruce Fields U. of Michigan, Center for Informaton Technology Integration (CITI) 535 West William Ann Arbor, Michigan Email: bfields@citi.umich.edu Gruenbacher & Fields Expires February 2, 2007 [Page 7] Internet-Draft NFSv4 file_masks Attribute August 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gruenbacher & Fields Expires February 2, 2007 [Page 8]