Red Hat, Inc.

bfields@redhat.com

Red Hat, Inc.

agruenba@redhat.com

Transport NFSv4 NFSv4 In some environments, inheritable NFSv4 ACLs can be rendered ineffective by the application of the per-process umask. This is easily worked around by transmitting the umask and create mode separately, to allow servers to make more intelligent decisions about the new mode of a file.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

On Unix-like systems, each process is associated with a file mode creation mask (umask). In the absence of inheritable permissions, the umask specifies which permissions must be turned off when creating new file system objects. With “POSIX” Access Control Lists , in the presence of inheritable permissions, the umask must be ignored. Other Access Control List implementations on Unix-like systems may ignore the umask in a similar way. The NFSv4 protocol currently does not include the umask concept; applying the umask is left to clients. Unfortunately, clients have no way of atomically checking for inheritable permissions and applying the umask only when necessary. Instead, they err on the safe side and always apply the umask. Thus the mode the server receives in an OPEN already has the umask applied. When applying the mode, section 6.4.1.1 of recommends that servers SHOULD restrict permissions granted to any user or group named in the ACL to be no more than the permissions granted by the MODE4_RGRP, MODE4_WGRP, and MODE4_XGRP bits. Servers aiming to provide clients with Unix-like chmod behavior may also be motivated by the same requirements in . (See the discussion of additional and alternate access control mechanisms in section "4.4 File Permissions".) On many existing installations, all ordinary users by default use the same effective group ID. To prevent granting all users full access to each other's files, such installations usually default to a umask with very restrictive permissions. Thus the named users and groups in an inherited ACL end up being mostly ignored. This leads to file permissions which are more restrictive than they should be in common cases; permission inheritance over NFSv4 is broken. To address this problem, a new attribute is proposed which allows the server to apply the umask only when there are no inheritable permissions.

struct mode_umask4 { mode4 mu_mode; mode4 mu_umask; };

Name Id Data Type Acc Defined in mode_umask 81 mode_umask4 W The NFSv4.2 mode_umask attribute is based on the open mode and umask that together determine the mode of a newly created UNIX file. Only the nine low-order mode4 bits of mu_umask are defined. A server MUST return NFS4ERR_INVAL if bits other than those nine are set. The mode_umask attribute is only meaningful for operations that create objects (CREATE and OPEN); the server SHOULD reject it for other operations that take fattr4 arguments. The server MUST ignore any mode attribute set in the same operation as mode_umask. When the server supports the mode_umask attribute, a client creating a file should use mode_umask in place of mode, with mu_mode set to the unmodified mode provided by the user, and mu_umask set to the umask of the requesting process. The server then uses mode_umask as follows: On a server that supports ACL attributes, if an object inherits any ACEs from its parent directory, mu_mode SHOULD be used, and mu_umask ignored. 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 to use for creating the object becomes (mu_mode & ~mu_umask) instead.

The mode_umask attribute shifts to the server the decision about when to apply the umask. Because the server MUST apply the umask if there are no inheritable permissions, the traditional semantics are preserved in the absence of a permission inheritance mechanism. The only relaxation of permissions comes in the case servers follow the recommendation that they SHOULD ignore the umask in the presence of inheritable permissions. The practice of ignoring the umask when there are inheritable permissions in the form of a “POSIX” default ACL is common practice; there are no known security concerns. The “POSIX” default ACL mechanism and the mechanism of inheriting permissions in NFSv4 is equivalent for this purpose.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

IETF Trust Network Appliance, Inc. Sun Microsystems, Inc. Network Appliance, Inc. Network Appliance, Inc. Sun Microsystems, Inc. Network Appliance, Inc. Network Appliance, Inc. Dell Dell The Open Group Portable Applications Standards Committee of the IEEE Compute Society

Thanks to Dave Noveck and Trond Myklebust for review.