Re: [nfsv4] WG Last Call for Extension and Minor Versions, Extended Attributes, and ACLs / Umask - Ends Dec 2nd 2016

["J. Bruce Fields" <[e-mail]>]

On Mon, Dec 12, 2016 at 04:32:09PM -0500, J. Bruce Fields wrote:
> On Thu, Dec 08, 2016 at 02:21:44PM -0800, spencer shepler wrote:
> > Given how the reference is used, I would be more direct about the
> > implementation.  As stated in the draft, this mechanism is needed for
> > unix-like (e.g. Linux) to appropriately apply the umask logic in the face
> > of an ACL implementation.  As Dave suggests, if there is a Linux man page
> > with this logic captured, then quote it in the RFC and make the reference
> > (quoted text could be in an appendix).  If there is concern about copyright
> > (and rightfully so), then just make the general reference and it would be
> > good to have more elaboration of the requirements if the I-D is not fully
> > self-contained.  Would also be good to know the Solaris behavior but
> > realistically this is being done for Linux, right?
> 
> Right, so I think it would be enough to say "here's how we know it works
> on Linux, other systems using mode bits and acls are likely to run into
> the same problem".
> 
> OK, I'll think about how to do that.

As suggested, I'm removing the reference to the POSIX draft that we
weren't sure we could give a stable reference for, and use a reference
to the relevant Linux man page instead.

I also rewrote the "Problem Statement" section to lead with the problem
statement and logic leading to the solution instead of leading with the
reference to the POSIX draft.

Results follow.--b.

2.  Problem Statement

   On Unix-like systems, each process is associated with a file mode
   creation mask (umask), which specifies which permissions must be
   turned off when creating new file system objects.

   When applying the mode, section 6.4.1.1 of [RFC7530] 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 [SUSv4].  (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.  As a result, inherited ACEs
   describing the permissions to be granted to named users and groups
   are often ignored.  This makes inheritable ACLs useless in some
   common cases.

   Linux solves this problem on local filesystems by ignoring the umask
   in the case the parent of the newly-created file has inheritable
   ACEs; see [LinuxACL].

   The same solution should work for NFS.  However, the NFSv4 protocol
   does not currently give the client a way to transmit the umask of the
   process opening a file.  And clients have no way of atomically
   checking for inheritable permissions and applying the umask only when
   necessary.  As a result, the server receives an OPEN with a mode
   attribute that already has the umask applied.

   This document solves the problem by defining a new attribute which
   allows the client to transmit umask and open mode separately,
   allowing the client to ignore the umask in the presence of
   inheritable ACLs.

....

7.2.  Informative References

   [LinuxACL]
              Gruenbacher, A., "ACL(5) - Access Control Lists", Linux
              man pages section 5 ACL, March 2002.