Re: [nfsv4] one umask-02 question

"J. Bruce Fields" <bfields@fieldses.org> Thu, 01 December 2016 22:01 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 E0ABC1299A7 for <nfsv4@ietfa.amsl.com>; Thu, 1 Dec 2016 14:01:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.798
X-Spam-Level:
X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 ZuFQThS2bFox for <nfsv4@ietfa.amsl.com>; Thu, 1 Dec 2016 14:01:43 -0800 (PST)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id E5A4C1299A3 for <nfsv4@ietf.org>; Thu, 1 Dec 2016 14:01:38 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id C09704CAD; Thu, 1 Dec 2016 17:01:37 -0500 (EST)
Date: Thu, 1 Dec 2016 17:01:37 -0500
From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20161201220137.GA1589@fieldses.org>
References: <3471.1480623047@athyra-vm1.us.oracle.com> <CADaq8jeHsqRi8PEJPVs0uma_9TjGrFVj=-yq-4NF-9awX6wP0g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADaq8jeHsqRi8PEJPVs0uma_9TjGrFVj=-yq-4NF-9awX6wP0g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/_ucvoP2JbvzCT0Z4VFVHTtnDW7w>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] one umask-02 question
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, 01 Dec 2016 22:01:46 -0000

On Thu, Dec 01, 2016 at 04:49:18PM -0500, David Noveck wrote:
> > I don't understand why the server doesn't return an error in
> > this case.
> 
> I'm not sure either.  Part of the problem may be that it isn't clear what
> error to return.  INVAL is ised to inicate an unknown attribute or one used
> with the wrong operation (get vs. set)

It has other uses too; e.g. see rfc5661 6.2.5, which is very similar:

	If the mode and mode_set_masked attributes are both specified in
	the same SETATTR, the server MUST also return NFS4ERR_INVAL.

I think INVAL would be fine.

> so maybe we would need NFS4ERR_BADATTRCOMB.
> 
> > Silently throwing stuff away makes me nervous.
> 
> I can see how that statement would raise red flags.
> 
> On the other hand, suppose there were no such statement and a create
> contained both mode and umask.  Allowing these to be applied in whatever
> order the server chooses is a recipe for non-interoperable
> implementations.  The natural thing is to say that if both of these
> attributes are present, umask is (MUST be) applied  last, in which case
> mode would have no effect.  The effect is the same as saying it MUST be
> ignored, but in this case, it is not a directive but a consequence of the
> fact that anything it says will be overwritten as part of creating the file.

I don't have any strong reason to care whether we require mode to be
ignored (or, equivalently, applied first), or we require INVAL be
returned.  Andreas, am I missing anything?

--b.

> 
> > (If this was already discussed, feel free to just give me a
> > pointer to the discussion.)
> 
> D
> 
> On Thu, Dec 1, 2016 at 3:10 PM, Mike Kupfer <mike.kupfer@oracle.com> wrote:
> 
> > Section 3 has
> >
> > >    The server MUST ignore any mode attribute set in the same operation
> > >    as mode_umask.
> >
> > I don't understand why the server doesn't return an error in this case.
> > Silently throwing stuff away makes me nervous.  (If this was already
> > discussed, feel free to just give me a pointer to the discussion.)
> >
> > thanks,
> > mike
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >

> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4