Re: [nfsv4] one umask-02 question

David Noveck <> Thu, 01 December 2016 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4FAE12995D for <>; Thu, 1 Dec 2016 13:49:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mm83HT8uXLhq for <>; Thu, 1 Dec 2016 13:49:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42CC51294E4 for <>; Thu, 1 Dec 2016 13:49:19 -0800 (PST)
Received: by with SMTP id m75so24923626oig.1 for <>; Thu, 01 Dec 2016 13:49:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w9lWLIIlCaaUOPd3uVPaxNG6tR4ubzQLq4hmoseu1vA=; b=LKy3xCPu4T3U5+zwOacAD2osBngJQYbUYYs4wy0aNzGDy3gr9iTAypy1r12i57/ciq l+7+5oQucJjENCbSrOBrXLwa2cKrrqwi4YmvHC/amnQOAWaQel2t5rYJi5EdKbuqBAYm ok+tjIgCnGBjiX5s4J9kr5ylmvzL6rSjam5BMR5uRZ0/4DOkLN6aZIM4otPpKCRiDvSE 2XAumMupzidK40OCzqR0zZI0cKKHgJWld0MzSQIPWrRbERBo2/gxA5ezuaCbPNCc/uxd ofs/xeEbDHcpXu3s1nl8aQnsg+T27o0NE0+INSLwd2nZ2aLIyjiOpSFob5tlJRmUGRC/ UcDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w9lWLIIlCaaUOPd3uVPaxNG6tR4ubzQLq4hmoseu1vA=; b=fLtLfxcddMrR0iHFgnWJUV5mTudjaXAwaaWFqKre7zmZNfJMWaLrqjylVFoF2vO6mY 7bPUlPoFvKnQcfE0n5MxbxA30OdGrZvadprq1AsDziQeYILIVoH8J+yqsqrUx872v49b PvF4LlNaUPL67ZrjrMYK/4z3WhxLBl+WuPK2eLt1JbjaeYwtxKdyeJnmWgn9t5MEXDEi 5MfeNQfwdL90SrFHXqFz28ktbpwDivbTKKNneGAppheyKyWI1w9lxRxKv9f5d2CsNtBe JcRKpHw57iAV3AWWCCFKzwpJ1wbTMRs+cwD0ugR06x9cc17eOYBtStEZT5+VO5qpeAzE r5SQ==
X-Gm-Message-State: AKaTC03qrWDyh6FdOTS2d0Z2ssWLUJOeoQNEKy7z5WLDF0OQYCXoVFqoYbvOscrKc6d0nI5pa+lPosfWtmATyQ==
X-Received: by with SMTP id j110mr21021642otc.208.1480628958630; Thu, 01 Dec 2016 13:49:18 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Dec 2016 13:49:18 -0800 (PST)
In-Reply-To: <>
References: <>
From: David Noveck <>
Date: Thu, 01 Dec 2016 16:49:18 -0500
Message-ID: <>
To: Mike Kupfer <>, "J. Bruce Fields" <>,
Content-Type: multipart/alternative; boundary="001a11493cae1f9aab05429fcbae"
Archived-At: <>
Cc: "" <>
Subject: Re: [nfsv4] one umask-02 question
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Dec 2016 21:49:21 -0000

> 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) so maybe we would need

> 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.

> (If this was already discussed, feel free to just give me a
> pointer to the discussion.)


On Thu, Dec 1, 2016 at 3:10 PM, Mike Kupfer <> 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