draft-ietf-nfsv4-umask-00.txt   draft-ietf-nfsv4-umask-01.txt 
NFSv4 J. Fields NFSv4 J. Fields
Internet-Draft A. Gruenbacher Internet-Draft A. Gruenbacher
Intended status: Informational Red Hat Intended status: Informational Red Hat
Expires: October 10, 2016 April 08, 2016 Expires: April 3, 2017 September 30, 2016
Allowing inheritable NFSv4 ACLs to override the umask Allowing inheritable NFSv4 ACLs to override the umask
draft-ietf-nfsv4-umask-00 draft-ietf-nfsv4-umask-01
Abstract Abstract
In some environments, inheritable NFSv4 ACLs can be rendered In some environments, inheritable NFSv4 ACLs can be rendered
ineffective by the application of the per-process umask. This is ineffective by the application of the per-process umask. This is
easily worked around by transmitting the umask and create mode easily worked around by transmitting the umask and create mode
separately to allow servers to make more intelligent decisions about separately, to allow servers to make more intelligent decisions about
the new mode of a file. the new mode of a file.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2016. This Internet-Draft will expire on April 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 9 skipping to change at page 4, line 9
any ACEs from its parent directory, mu_mode SHOULD be used, and any ACEs from its parent directory, mu_mode SHOULD be used, and
mu_umask ignored. mu_umask ignored.
o Otherwise, mu_umask MUST be used to limit the mode: all bits in o Otherwise, mu_umask MUST be used to limit the mode: all bits in
the mode MUST be turned off which are set in the umask; the mode the mode MUST be turned off which are set in the umask; the mode
to use for creating the object becomes (mu_mode & ~mu_umask) to use for creating the object becomes (mu_mode & ~mu_umask)
instead. instead.
4. Security Considerations 4. Security Considerations
The proposed attribute allows to shift the decision when to apply the The mode_umask attribute shifts to the server the decision about when
umask to the server. Becuse the server MUST apply the umask if there to apply the umask. Because the server MUST apply the umask if there
are no inheritable permissions, the traditional semantics are are no inheritable permissions, the traditional semantics are
preserved in the absence of a permission inheritance mechanism. The preserved in the absence of a permission inheritance mechanism. The
proposal specifies that servers SHOULD ignore the umask if there are only relaxation of permissions comes in the case servers follow the
inheritable permissions, allowing servers to ignore this recommendation that they SHOULD ignore the umask in the presence of
recommendation in cases when that should be preferable. inheritable permissions.
The practice of ignoring the umask when there are inheritable The practice of ignoring the umask when there are inheritable
permissions in the form of a "POSIX" default ACL is common practice; permissions in the form of a "POSIX" default ACL is common practice;
there are no known security concerns. The "POSIX" default ACL there are no known security concerns. The "POSIX" default ACL
mechanism and the mechanism of inheriting permissions in NFSv4 is mechanism and the mechanism of inheriting permissions in NFSv4 is
equivalent for this purpose. equivalent for this purpose.
5. Normative References 5. Normative References
[LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents", [LEGAL] IETF Trust, "Legal Provisions Relating to IETF Documents",
 End of changes. 6 change blocks. 
9 lines changed or deleted 9 lines changed or added

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