Re: [nfsv4] one umask-02 question

[Andreas Gruenbacher <[e-mail]>]

On Thu, Dec 1, 2016 at 11:01 PM, J. Bruce Fields <[e-mail]> wrote:
> 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?

Ignoring the mode attribute when mode_umask is set should be the
easiest thing to implement; returning INVAL will always require
additional code that doesn't actually add any benefits. If it makes
anyone feel better, we might just as well require INVAL to be
returned, though.

Thanks,
Andreas