Subject: [nfsv4] [[email-masked]: New Version Notification for draft-bfields-nfsv4-umask-00.txt]

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 3 Feb 2016 16:23:14 -0500

NFSv4 ACL inheritance doesn't really work if your umask masks out group
bits.  This has been a long-standing complaint from people attempting to
adopt NFSv4 ACLs.

The solution used to for "POSIX" ACLs on Linux has been to ignore the
umask when inheritable ACLs are present.

You could try implementing that client-side by querying the parent
directory ACL and deciding what to do based on that; but that solution
is complicated and race-prone.

It's much more easily done with a very simple addition to the protocol,
described here.

Any feedback welcome.

--b.

----- Forwarded message from [email-masked] -----

Date: Wed, 03 Feb 2016 13:00:42 -0800
From: [email-masked]
To: Andreas Gruenbacher <[email-masked]>, "J. Bruce Fields"
	<[email-masked]>
Subject: New Version Notification for draft-bfields-nfsv4-umask-00.txt

A new version of I-D, draft-bfields-nfsv4-umask-00.txt
has been successfully submitted by J. Bruce Fields and posted to the
IETF repository.

Name:		draft-bfields-nfsv4-umask
Revision:	00
Title:		Allowing inheritable NFSv4 ACLs to override the umask
Document date:	2016-02-03
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-bfields-nfsv4-umask-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bfields-nfsv4-umask/
Htmlized:       https://tools.ietf.org/html/draft-bfields-nfsv4-umask-00

Abstract:
   In some environments, inheritable NFSv4 ACLs can be rendered
   ineffective by the application of the per-process umask.  This is
   easily worked around by transmitting the umask and create mode
   separately to allow servers to make more intelligent decisions about
   the new mode on a file.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 3 Feb 2016 16:50:05 -0500

Hi Bruce,

> It's much more easily done with a very simple addition to the protocol,

Could you not achieve the same effect by essentially adding an
attribute that supplies the 'raw' (unmasked? non-masked?) mode bits?

The reason for wanting to do this instead of adding a 'umask'
attribute is for compatibility reasons: the client can continue to
send the exact same information that it does currently in the existing
mode bit field, while supplying the 'raw' mode bit information in the
new attribute. The server then decides which one to use at file
creation time based on whether or not a default ACL is being applied.

Cheers
  Trond

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 4 Feb 2016 16:39:43 -0500

> creation time based on whether or not a default ACL is being applied.

Yeah, Andreas and I had this dicussion too.

The two options, either of which would work:

	1. 'mode', 'raw_mode': 'mode' is the mode with umask applied, the
	   same thing we currently send, 'raw_mode' is the un-umasked
	   value.
	2. 'mode', 'umask': but we put the un-umasked raw mode in 'mode'.

The two attributes are always sent in the same op.  The redefinition of
'mode' in option 2 is safe since the presence of the new 'umask'
attribute would cause an old server to reject the op.

Any server implementation will likely just set its umask to the given
umask and let common VFS logic take care of the inheritance decision.
That's simplest with option 2.  But you can do it with option 1 too,
just use raw_mode&~mode as the umask.  That umask may differ from the
client's original umask, which Andreas thought might be slightly less
debugging friendly.

In the end we decided we liked #2 better, but I don't think either of us
feels terrifically strong about it.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 4 Feb 2016 18:41:30 -0500

> feels terrifically strong about it.

One argument would be that the minor versioning rules in RFC7530 and
RFC5661 and Dave's new "versioning" draft don't allow you to change
the content of an existing attribute. They talk only of adding new
attributes, and/or marking existing attributes as MUST NOT be
implemented.

Granted, you are not changing the attribute in a way that changes the
fundamental type, but there could be tools out there that inspect
these attributes and expect a certain behaviour (Jorge's nfstests code
comes to mind).

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 5 Feb 2016 11:32:45 -0500

> these attributes and expect a certain behaviour (Jorge's nfstests code

OK, that's worth thinking about.

>From the point of view of a tool examining the protocol behavior,
examination of setattr's alone probably won't show any interesting
difference--"mode" values are all still in the same range, after all.

Such a tool would only see a difference if they also compare the setattr
with, for example, later getattr results.  But then they see some change
no matter which option we choose:

	- With option 1, a subsequent getattr may show a mode more
	  permissive than the one in the setattr, if inheritable ACLs
	  are present.

	- With option 2, a subsequent getattr may show a mode more
	  restrictive than the one in the setattr, if no inheritable
	  ACLs are present.

The no-inheritable ACLs case may currently be more common (partly
because we haven't solved this problem).  So maybe preserving that case
is more important?

But I think either change is reasonable for a protocol extension and
exceedingly unlikely to break any tools.

I'm still inclined to stick with (open mode, umask).

--b.

---

From: David Noveck <[email-masked]>
Date: Fri, 5 Feb 2016 12:36:46 -0500

The minor versioning rules in RFCs 3530 and 5661 were focused on XDR
changes.
They didn't mention, either to explicitly allow or to forbid the kind of
behavioral changes
we are discussing here.  Those rules don't really deal with those sorts of
changes.

draft-ietf-nfsv4-versioning does deal with behavioral changes.  The
intention is that
if there is a change of required or allowed behavior for existing requests,
that is a change
that requires minor version bump, so the minor version number tells us
whether the old or new
rules apply.

No matter which way you go on the naming or definition of the new
attribute, the behavior for old
requests stays the same.  If the new attribute is not specified on the
operation creating the
file the required and allowed server behavior stays the same.  The mode
attribute specified
is to become the mode of the created file.

It is true that clients are well-advised to store a different value in the
mode attribute if the
server supports the new attribute but this sort of advice about how a
client might use the
protocol, while helpful, does not really restrict what an extension is
allowed to do:

BTW, the "should" in the following fragment from the current draft is
correct but I don't think
the "SHOULD NOT" is:

> When both the server and client support the umask attribute, a client
> that creates a file SHOULD NOT apply the umask to the mode attribute
> set at creation time.  Instead, it should set the mode attribute to
> the unmodified mode provided by the user, and the umask attribute to
> the umask of the requesting process.

My suggested replacement would be:

When the server supports the umask attribute, a client that creates a
file should not

apply the umask to the mode attribute set at creation time, as this is
likely to result in

unduly restrictive permissions when ACEs are inherited by the created
file.. Instead,

it should set the mode attribute to the unmodified mode provided by
the user, and the

umask attribute to the umask of the requesting process.

Despite the fact that the umask attribute is a valid extension, making this
a second mode attribute seems
better to me in that it directly reflects the server's task. In any case,
the server is basically being told to use
one of two mode values based on the permission inheritance. Saying that the
second mode is expressed as
a boolean combination of two different attributes seems a roundabout way to
express this.

sort

On Thu, Feb 4, 2016 at 6:41 PM, Trond Myklebust <[email-masked]> wrote:

> >> > URL:
> https://www.ietf.org/internet-drafts/draft-bfields-nfsv4-umask-00.txt
> >> > Status:
> https://datatracker.ietf.org/doc/draft-bfields-nfsv4-umask/
> >> > Htmlized:
> https://tools.ietf.org/html/draft-bfields-nfsv4-umask-00
> >> >
> >> >
> >> > Abstract:

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 5 Feb 2016 16:08:08 -0500

> My suggested replacement would be: When the server supports the umask
> attribute, a client that creates a file should not apply the umask to
> the mode attribute set at creation time, as this is likely to result
> in unduly restrictive permissions when ACEs are inherited by the
> created file.. Instead, it should set the mode attribute to the
> unmodified mode provided by the user, and the umask attribute to the
> umask of the requesting process.

Agreed to lower-casing the SHOULD NOT and leaving out the client support
requirement as that's implicit; I've made both changes.  I left out the
"as this is likely..." for concision, since I feel that's adequately
covered by the previous section.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 6 Feb 2016 16:38:51 -0500

On Fri, Feb 5, 2016 at 12:36 PM, David Noveck <[email-masked]> wrote:
> No matter which way you go on the naming or definition of the new attribute,
> the behavior for old
> server supports the new attribute but this sort of advice about how a client
> might use the
> When the server supports the umask attribute, a client that creates a file
> should not
>
> unduly restrictive permissions when ACEs are inherited by the created file..
> Instead,
>
> it should set the mode attribute to the unmodified mode provided by the
> user, and the
>

Even with this wording, how does the client guarantee that the server
applied the umask?

AFAICS, there is no wording in RFC5661 or RFC7530 that requires a
server to reject the OPEN if it doesn't understand the umask
attribute. So it is perfectly allowable for a server to create the
file and simply apply the mode bits that were supplied, leading to a
less restrictive set of permissions on the file than the user
intended.

> a boolean combination of two different attributes seems a roundabout way to

Agreed.

---

From: David Noveck <[email-masked]>
Date: Sat, 6 Feb 2016 21:32:01 -0500

The text in question says

> When the server supports the umask attribute ...

If a server supports an attribute, then it has to do what the definition of
attribute says.

I don't see how a server can claim to support an attribute, either by
turnng on the appropriate bit in supported_attrs or by not returning an
error when it is presented in a fattr4, and then just ignore the
specification of that attribute.  Such a server is broken by definition.

Neither RFC7530 nor RFC5661 were as clear as they should be on the errors
to be returned when an invalid fattr4 is presented by a client.  Perhaps
errata are needed.

Does anyone know of a server that:

   - Does not return NFS4ERR_INVAL if the bitmap contains some bit not
   specified as corresponding to an attribute?
   - Does not return NFS4ERR_ATTRNOTSUPP if the bitmap contains some bit
   corresponding to an attribute known to the server that the server does not
   support?

On Sat, Feb 6, 2016 at 4:38 PM, Trond Myklebust <[email-masked]> wrote:

> client
> file
> file..

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 6 Feb 2016 22:29:42 -0500

> If a server supports an attribute, then it has to do what the definition of

Apparently not, since you are arguing that definition can be changed
by future drafts.

> I don't see how a server can claim to support an attribute, either by turnng
> on the appropriate bit in supported_attrs or by not returning an error when
> it is presented in a fattr4, and then just ignore the specification of that
> attribute.  Such a server is broken by definition.

There is no normative language in either spec to support that definition.

> Neither RFC7530 nor RFC5661 were as clear as they should be on the errors to
> be returned when an invalid fattr4 is presented by a client.  Perhaps errata
> are needed.

Look at SETATTR. It returns a bitmask that represents the attributes
that were set, implying that the server doesn't need to set all. There
is also language in the RFC5661 Section 18.30.4. to the effect that
"SETATTR is not guaranteed to be atomic".

Ditto for OPEN and CREATE; the returned bitmask indicates which
attributes were set, again implying that the server doesn't need to
set all bits.

Why are we wasting bytes in these return values if the intention was
that the server should return NFS4ERR_INVAL every time it couldn't set
an attribute? Agreed that exclusive OPEN has the special case of
needing to store the verifier, but that doesn't explain SETATTR or
CREATE.

> Does not return NFS4ERR_INVAL if the bitmap contains some bit not specified
> as corresponding to an attribute?
> Does not return NFS4ERR_ATTRNOTSUPP if the bitmap contains some bit

---

From: David Noveck <[email-masked]>
Date: Sun, 7 Feb 2016 08:49:52 -0500

> Apparently not, since you are arguing that definition can be changed

I'm not arguing that it can be changed by future drafts or even by
extensions approved as  Proposed Standards.

I guess the versionIng document says the interpretation (but not the
type definition)  can be changed in a future minor version but that is only
because the emphasis is on saying it cannot be changed in
an extension.  I'm open to suggestions on tightening this up.  In any case,
this shouldn't be a problem in practice since I don't think there could be
a consensus for any significant change in the interpretation of
an existing attribute.

> > I don't see how a server can claim to support an attribute, either by
turnng

> There is no normative language in either spec to support that definition.

Perhaps not but if one wrote a server that only obeyed normative language
in the spec, it wouldn't be very useful.

I just can't imagine the protocol defining a supported_attrs attribute and
having it be essentially meaningless, which is what I think your position
allows.  It would be possible to add enough MUSTs to prevent that, but if
we were to take that approach, we'd have to have lawyers writing the specs,
and I don't think that would be a good idea.

> that were set, implying that the server doesn't need to set all.

To me. all it implies is that someone, at some time, thought there might
be some situations
in which all the attributes requested to be set could not be set and an
error still not returned.

It is a big jump to go from there to essentially say that a server MAY (for
essentially any reason or
no reason) just decide not to store any requested attribute (presumably in
the case of a non-REQUIRED
attribute) and return OK with the corresponding attribute bit not set.

Is that what you are saying?  For example, if you do a SETATTR of mode (for
a chmod) on a file
system that supports the mode attribute, is it ok for it to do nothing and
return OK with zero-length
attrset?  Sounds like a recipe for chaos.

> There

I think that just means GETATTR might see some of the attributes set
but not others that were eventually set.

> attributes were set, again implying that the server doesn't need to

In some cases perhaps, but not in all cases, or else there would no
need for these ops to return NFS4ERR_ATTRNOTSUPP.

> Why are we wasting bytes in these return values

I'm not sure.  All I know is that the attrsset bit map was first defined as
part of the
response for SETATTR in RFC3010. Then, when OPEN and CREATE were given
the ability to set attributes in RFC3530, the idea of returning a bit map
was carried
over to CREATE and OPEN.  RFC5661 kept things the same since 8-12 bytes in
these responses was not a big issue.

> if the intention was
> an attribute?

I don't think that's the intention.  I think the intention is that
NFS4ERR_INVAL has to
be returned regarding attributes you don't support for the requested
operation if:

   - The caller requested you set a read-only attribute.
   - The caller requested you set an attribute number that is not defined
   as a valid attribute for the current minor version (e.g attribute 100 for
   v4.0).
   - The caller requested you set an attribute number that is defined as
   part of an extension you were not built to deal with (e,g, attribute 81
   sent to an unextended v4.2 server).

As far as other errors, I believe the intention is:

   - If the attribute is an otherwise valid one and you don't support it,
   NFS4ERR_ATTRNOTSUPP is to be returned.
   - If you  are setting an ACL and it contains ACEs that you don't
   support, NFS4ERR_ATTRNOTSUPP is to be returned.

The error overloading is regrettable but I don't see what we can do about
it.

   - if the attribute is one you support and an IO error means you can't
   set it, NFS4ERR_IO is to be returned.

I think there are a few cases in which it is valid to return NFS4ERR_INVAL
for an attribute you support.

   - If the operation specifies an invalid value for a particular attribute.
   - If attr_vals is not large enough to accommodate
   all specified attributes (and an XDR decode error is not signalled)

As to the remainder, i.e. returning OK and not setting the attribute, I
can't identify a specific situation in which this would be
appropriate but can't say that these situations don't exist, other than for
OPEN exclusive.   Does anybody know of a case?

On Sat, Feb 6, 2016 at 10:29 PM, Trond Myklebust <[email-masked]> wrote:

> turnng
> >> > we are discussing here.  Those rules don't really deal with those
> sorts
> >> > of
> >> > changes.
> >> >
> the
> >> > one of two mode values based on the permission inheritance. Saying
> that
> >> > the
> >> > a boolean combination of two different attributes seems a roundabout
> way
> >> > to
> >> > express this.
> >>
> >> Agreed.
> >
> >
>

---

From: Trond Myklebust <[email-masked]>
Date: Sun, 7 Feb 2016 13:53:56 -0500

> I'm still inclined to stick with (open mode, umask).

Imagine that I've got a filesystem that can store ACLs but not mode
bits (*cough* NTFS *cough*). I currently have 2 implementation choices
in front of me:

1) Support the existing optional mode attribute, and break ACLs on
file creation.
2) Support ACLs only, and don't support the mode attribute.

Your draft adds a third option:

1.b) Support the existing optional mode, and break ACLs on file
creation only if a POSIX client doesn't split mode into raw+umask.

Now where is option 2b?

2.b) Support ACLs only. Don't support an optional mode unless the
POSIX client supplies a raw mode.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 8 Feb 2016 10:12:21 -0500

> less restrictive set of permissions on the file than the user

My understanding has always been that the server was required to fail
the operation completely in case of an unsupported attribute, with
partial success only allowed in the read (GETATTR) case.

Looking at 7530:

	- NFS4ERR_ATTRNOTSUPP is a legal return for SETATTR, CREATE,
	  OPEN, VERIFY, and NVERIFY.

	- there is explicit text in the "implementation" sections for
	  NVERIFY, VERIFY and SETATTR.  (E.g., SETATTR: "If the server
	  does not support an attribute as requested by the client, the
	  server should returrn NFS4ERR_ATTRNOTSUPP.")

	- on CREATE, createattrs says nothing about an error but just
	  says "When the operation is successful, the server will return
	  to the client an attribute mask signifying which attributes
	  were succesfully set for the objects." OPEN has similar
	  language (for UNCHECKED and GUARDED cases).

My interpretation has always been that:

	- on attribute-setting operations the server should vet the
	  attribute bitmask before executing the operation, returning
	  ATTRNOTSUPP in case of any unsupported attributes.

	- the returned bitmask is there only for errors that couldn't be
	  anticipated before executing the operation.  (The spec
	  acknowledges that the server may not necessarily be able to
	  roll back a file create or partial setattr on failure.)

But perhaps the spec is too ambiguous to allow us to count on that
interpretation.

--b.

---

From: David Noveck <[email-masked]>
Date: Mon, 8 Feb 2016 12:07:59 -0500

> POSIX client supplies a raw mode.

Not sure about some details of what is being proposed here.  It seems that
both mode and
raw-mode would be in supported_attrs.  So you can't return
NFS4ERR_ATTRNOTSUPP
if mode is specified in a create/open and raw-mode isn't.
Returning NFS4RR_INVAL
seems troublesome  in that existing clients would not be prepared for it,
and I think it
would violate draft-ietf-nfsv4-versioning rules for an extension, although
it could be
done in a new (*cough* minor *cough*) version.

How about:

2.c) define a new optional create-mode-pair attribute (consisting of
masked_mode
and  raw_mode) instead of either umask or raw-mode attribute.

> (*cough* NTFS *cough*)

Servers exporting non-cough-inducing fs's could support mode and
create-mode-pair
while those exporting cough-inducing fs's might support only
create-mode-pair.

Two things to resolve:

   - Handling when both mode and create-mode-pair are specified.

I'd prefer it if create-mode-pair had priority although making this return
NFS4ERR_INVAL is OK.

   - What attrset bits are returned when both are specified.

I prefer the one actually used but you could decide that both are set, or
that what is returned depends on whether permissions were inherited.

BTW, this same issue would need to be clarified if either raw-mode or umask
were implemented, especially in the umask case since the
umask attribute may be used as part of create but is never actually set

---

From: David Noveck <[email-masked]>
Date: Mon, 8 Feb 2016 12:20:20 -0500

> POSIX client supplies a raw mode.

Not sure exactly what is being suggested here.  It seems that both mode and

How about:

create-ode-pair

Two things to resolve:

BTW, this same issue would also need to be clarified if either raw-mode or
umask were implemented, especially in the umask case since the
umask attribute may be used as part of create but is never actually set

---

From: [email-masked] (J. Bruce Fields)
Date: Mon, 8 Feb 2016 13:35:57 -0500

> POSIX client supplies a raw mode.

It took me a moment to understand what you were asking for.  OK, so
you're suggesting a server might want to support (mode, umask), but not
mode on its own.  Neither of the options we've discussed ((mode, umask)
or (mode, raw_mode)) allow the server to do that.

I don't know how likely that is--every server I've seen has made an
effort to support mode bits even when it was unnatural for them.  But it
seems easy enough to allow, so, OK.  Noveck's idea of making the new
attribute a pair sounds good to me.

--b.

---

From: [email-masked] (J. Bruce Fields)
Date: Mon, 8 Feb 2016 13:54:22 -0500

> umask attribute may be used as part of create but is never actually set

I don't care too much, except that I certainly wouldn't want to require
that the server determine whether the umask was actually applied or not.

I expect that would be difficult for the server, and don't know of any
existing client interfaces that would actually use that information.

(In more detail: a Linux-based server implementation, for example, will
probably set the process umask and then call open.  But open doesn't
return a "was the umask applied" bit.  We could attempt to determine
that after the fact, but that would be complicated and race-prone.  We
could add new interfaces to do this atomically, but that would be
annoying for an in-kernel server, and *really* annoying for a userspace
server.)

--b.

---

From: [email-masked] (J. Bruce Fields)
Date: Tue, 9 Feb 2016 10:52:26 -0500

> less restrictive set of permissions on the file than the user

Wait, how would such a server even parse the createattrs?  The
attributes in fattr4.attr_vals aren't self-describing.  So I think the
only reason we're even allowing new attributes in existing minor
versions is because we assume that legacy servers will reject without
even trying to execute the operation.

OK, I guess a server could also just give up at the first unknown
attribute and skip parsing the rest of attr_vals.  Still, that seems
like an odd choice.  I'd be surprised if any 4.2 server ever has that
behavior.

But we can design this extension without that assumption if we think
there's a real risk.

> > one of two mode values based on the permission inheritance.

Note it's not that general--many servers probably won't be capable of
handling a (mask, raw_mask) pair if there is a bit set in "mask" that is
also not set in "raw_mask", for example.

> > Saying that the second mode is expressed as a boolean combination of
> > two different attributes seems a roundabout way to express this.

So the spec would still need language to the effect that mode&~raw_mode
must be zero.  And will probably still need some language discussing
umask if only as motivation.  And in practice clients and servers will
be dealing in (mode, umask) internally.

(mode, raw_mode) seemed like the more straightforward option to me too
on first look, but I convinced myself it's not.

--b.

---

From: David Noveck <[email-masked]>
Date: Tue, 9 Feb 2016 12:40:13 -0500

> So I think the

draft-ietf-nfsv4-versioning assumes that server will return NFS4ERR_INVAL
in this case, but it might be that some will return NFS4ERR_ATTRNOTSUPP.
If anyone knows about such servers, let me know and I'll adjust the draft.

> like an odd choice.

Very odd.  I think we've already discussed a server checking up front for
attributes it doesn't support failing then and there.  So, for this to
happen
a server would have to see an unknown attribute, confidently assume that
he supports this unknown attribute and only later realize that it is quite
hard to support attributes you never heard of.

> And in practice clients and servers will

Clients probably but I can't see why a server would do that.

> on first look, but I convinced myself it's not.

Did you use any arguments that would convince anyone else :-)

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 9 Feb 2016 14:28:39 -0500

>From a quick check of linux knfsd code--looks like it probably returns
BAD_XDR in the case of a completely unknown attribute, and ATTRNOTSUPP
in the case of an attribute not supported on this filesystem.

> Clients probably but I can't see why a server would do that.

So, as the first example, take a userspace Linux server.  It's going to
implement this using the only available interface available to it:

	umask(umask);
	open(.,.,mode);

That will atomically create the file and propagate inheritable ACLs or
apply the umask as appropriate.

(If such a server instead tried to do the ACL stuff by hand, the results
would be a) more complicated, b) prone to races with other users of the
exported filesystem.)

The in-kernel Linux server has some more wiggle room, but will end up
doing basically the same set-umask-then-open thing.

And if you're supporting a unix-like userland that also has access to
the exported filesystem, then you likely end up doing that too.
(Because you already support the umask, and will likely want the same
logic for local users.  And then it's easiest to put that logic in one
place and have the NFS server invoke it in the same way other users do.)

If your server doesn't have any local users then maybe you can add
another parameter to your open call, or do something like:

	lock(parent)  /* to prevent other threads modifying ACL */
	if (file_would_inherit_ACEs(parent))
		open(.,.,raw_mode)
	else
		open(.,.,mode)
	unlock(parent)

I don't know.

But there's still a significant group of servers that have to do deal in
mode and umask, so the spec will need language like:

	Every bit set in "mode" must also be set in "raw_mode", and the
	server MUST return NFS4ERR_INVAL if this is not the case.

Or maybe:

	The server sets the mode to mode|raw_mode in the presence of
	inheritable ACLs.

But then this seems to be a roundabout way of expressing constraints
that are due to implementations actually using (mode, umask)
internally.

Sorry, that was long, does it explain anything?  I'm not sure whether
I'm just hard to understand, or if you understand the point but think
it's stupid....

--b.

---

From: David Noveck <[email-masked]>
Date: Tue, 9 Feb 2016 15:56:23 -0500

> in the case of an attribute not supported on this filesystem.

This doesn't seem right to me, although I can warn clients that it might
happen.

In any case, the recommended way to deal with this is to get the value of
supported_attrs
in advance and I can't see a server returning unknown attributes in that.

> Sorry, that was long, does it explain anything?

Kind of.

> I'm not sure whether I'm just hard to understand,

Why don't we wait until I say "I don't understand" before we consider why
that
might be?

> or if you understand the point but think it's stupid....

Not necessarily.  I think it reflects a Linux-oriented approach to things
that I
don't share.  I find it understandable, but not natural, at least as I
approach
things.

---

From: Christoph Hellwig <[email-masked]>
Date: Wed, 10 Feb 2016 17:14:43 +0100

> don't share.  I find it understandable, but not natural, at least as I

Note that the umask isn't a Linux invention - it applies to any OS / file
system with Posix semantics.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 22 Feb 2016 14:21:04 -0500

> system with Posix semantics.

I've uploaded another version, keeping the umask but adopting the idea
of a pair (so it's (mode, umask) now instead of umask).

Also, git repo for the source:

	git://linux-nfs.org/~bfields/NFSv4-umask.git
	http://git.linux-nfs.org/?p=bfields/NFSv4-umask.git

--b.

Name:		draft-bfields-nfsv4-umask
Revision:	01
Title:		Allowing inheritable NFSv4 ACLs to override the umask 
Document date:	2016-02-22
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-bfields-nfsv4-umask-01.txt
Status:         https://datatracker.ietf.org/doc/draft-bfields-nfsv4-umask/
Htmlized:       https://tools.ietf.org/html/draft-bfields-nfsv4-umask-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-bfields-nfsv4-umask-01

---

From: David Noveck <[email-masked]>
Date: Wed, 24 Feb 2016 05:36:22 -0500

I hope the new name, mode_umask, sticks.  I'm now preparing some slides for
our 3/29 conference about versioning issues and it is nice to be able to
take out the phrase "or whatever" about one of the two likely extensions
that I mention.

On Mon, Feb 22, 2016 at 2:21 PM, J. Bruce Fields <[email-masked]>
wrote:

> https://www.ietf.org/internet-drafts/draft-bfields-nfsv4-umask-01.txt
> Status:
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-bfields-nfsv4-umask-01
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 24 Feb 2016 10:11:31 -0500

> take out the phrase "or whatever" about one of the two likely extensions

Hah, OK, I'll try to stick to that name....

--b.