Allowing Inheritable NFSv4 Access Control Entries to Override the Umask
Extracted elements (15)
Linux local filesystems already ignore the umask whenever a newly created file inherits ACEs from its parent directory. The NFSv4 extension mirrors this established local-filesystem behavior to achieve equivalent semantics over NFS.
The attribute was defined as a (mode, umask) pair rather than just a umask alone, following reviewer suggestion, so the server has both the unmodified user-requested mode and the process umask and can apply the appropriate logic without needing additional round-trips.
The NFSv4 protocol previously gave clients no way to transmit the process umask separately from the mode; clients applied the umask before sending OPEN, so the server could not intelligently ignore it when inheritable ACEs were present. This extension solves that by conveying umask and mode as separate values.
This document extends NFSv4.2 via the extensibility rules in RFC 8178 but does not update RFC 7862 or RFC 7863. XDR additions must be merged into the base XDR from RFC 7863 together with any other extensions before compilation.
This extension targets NFSv4 minor version 2. NFSv4.2 servers and clients implemented without knowledge of this extension will continue to interoperate with implementations that are aware of it, whether or not they support it, because the feature is OPTIONAL.
A server MUST return NFS4ERR_INVAL if a client attempts to set both mode and mode_umask in the same operation.
A server MUST return NFS4ERR_INVAL if any bits other than the nine low-order bits are set in mu_umask.
If no ACEs are inherited, mu_umask MUST be used to limit the mode: all bits in mu_mode that are set in mu_umask MUST be turned off, yielding a final mode of (mu_mode & ~mu_umask).
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, allowing the inheritable ACEs to take full effect.
The mode_umask attribute is only meaningful for object-creation operations (CREATE and OPEN). In any other operation that takes fattr4 arguments, the server MUST reject the attribute with NFS4ERR_INVAL.
When the server supports the mode_umask attribute, a client creating a file should use mode_umask in place of mode, setting mu_mode to the unmodified user-provided mode and mu_umask to the umask of the requesting process.
The mode_umask attribute (FATTR4_MODE_UMASK, attribute ID 81) is a new NFSv4.2 OPTIONAL write-only fattr4 attribute that carries both the unmodified create-time mode and the process umask. It is defined as data type mode_umask4.
Ignoring the umask when inheritable permissions exist (via POSIX default ACLs) is long-standing practice and has not given rise to security issues. The POSIX default ACL mechanism and NFSv4 permission inheritance are considered equivalent from a security perspective.
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, traditional semantics are preserved in the absence of a permission inheritance mechanism; the only relaxation occurs when the server ignores the umask in the presence of inheritable permissions.
The mode_umask4 XDR structure contains two fields: mu_mode (type mode4, the unmodified mode specified at open time) and mu_umask (type mode4, the process umask). Only the nine low-order bits of mu_umask are defined.