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 Wed, Mar 01, 2017 at 05:19:38PM -0500, David Noveck wrote:
> Looks good.
> 
> I have few nits that you might want to address:
> 
> > See the discussion of
> >  additional and alternate access control mechanisms in section "4.4
> >   File Permissions".)
> 
> You might want to add "of that document: before the closing paren.

Thanks, done.

> > allows the client to transmit umask and open mode separately,
> 
> Suggest replacing "open mode" by "the mode specified at file creation"

And, done.

> At the end of the last paragraph, you might want to add:
> 
> This allows NFSv4 to provide the same semantics available using local
> access.

Added, with "At least in the Linux case, this allows...", as I don't
know about other client OS's.

--b.

> 
> 
> On Wed, Mar 1, 2017 at 5:01 PM, J. Bruce Fields <[e-mail]>
> wrote:
> 
> > 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.
> >