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

"J. Bruce Fields" <bfields@fieldses.org> Thu, 02 March 2017 00:55 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1B129478 for <nfsv4@ietfa.amsl.com>; Wed, 1 Mar 2017 16:55:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3D03k9Q8VXt for <nfsv4@ietfa.amsl.com>; Wed, 1 Mar 2017 16:55:43 -0800 (PST)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id EF2D4129455 for <nfsv4@ietf.org>; Wed, 1 Mar 2017 16:55:42 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id 939BA396; Wed, 1 Mar 2017 19:55:42 -0500 (EST)
Date: Wed, 01 Mar 2017 19:55:42 -0500
From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20170302005542.GA19519@fieldses.org>
References: <MWHPR03MB289323FB62D892F442482D9CC7830@MWHPR03MB2893.namprd03.prod.outlook.com> <CADaq8jewDSJZ7p3Kbjg43z0yhSWf20HcB+e+qgY35h0YavgryA@mail.gmail.com> <CAFt6BakDsGoo56KQPV-UGcCsPd=pUzrmy+j1DkGmy-6ryrDTbg@mail.gmail.com> <CADaq8jd42_UThHThuO-co5VSrU1go=QPiEXhu=rAdx6h2SSHYg@mail.gmail.com> <20161208202952.GB26583@fieldses.org> <CADaq8je-pL0yGUvzL2r7wjSWXeWZBf3DgF5APMDKQpD2ejY16Q@mail.gmail.com> <CAFt6Ba=yyVqyt3PJ6g_brUNt+Oy931kOuNw2sXtXWLe=CrqO8Q@mail.gmail.com> <20161212213209.GA6002@fieldses.org> <20170301220138.GB9545@fieldses.org> <CADaq8jfYeoYYaX2eKuObMJGBq_+TNcF45yNDi3E8evDYq6mCGA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jfYeoYYaX2eKuObMJGBq_+TNcF45yNDi3E8evDYq6mCGA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/L8natEJPB4WJcfbA3Uh2QIdrJa4>
Cc: "J. Bruce Fields" <bfields@redhat.com>, NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] WG Last Call for Extension and Minor Versions, Extended Attributes, and ACLs / Umask - Ends Dec 2nd 2016
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 00:55:44 -0000

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 <bfields@fieldses.org>
> 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.
> >