[nfsv4] Re: RFC: How to handle (N)VERIFY for Posix draft ACL attributes

[Chuck Lever <[e-mail]>]

On 5/20/25 8:18 PM, Rick Macklem wrote:
> On Tue, May 20, 2025 at 6:07 AM Chuck Lever
> <chuck.lever=[e-mail]> wrote:
>>
>> On 5/19/25 2:58 PM, David Noveck wrote:
>>>
>>>
>>> On Mon, May 19, 2025, 10:34 AM Chuck Lever
>>> <chuck.lever=[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     On 3/6/25 6:23 PM, Rick Macklem wrote:
>>>     > Hi,
>>>     >
>>>     > If I understood the previous discussion of this (I might not
>>>     have), the
>>>     > POSIX draft ACL draft needs one of the following:
>>>     >
>>>     > 1 - A statement that (N)VERIFY operations are not supported for the
>>>     >   attributes.
>>>     > or
>>>     > 2 - A description of how the POSIX draft ACL attributes are compared.
>>>     >   (If this alternative is preferred, my initial attempt would be
>>>     to state
>>>     >    that ACLs with the same set of ACEs but in a different ordering
>>>     would
>>>     >    be considered "same" for (N)VERIFY.)
>>>     >
>>>     > I, personally, prefer #1 since I do not think that applying
>>>     (N)VERIFY to
>>>     > the POSIX draft ACL attributes is useful, but I need feedback from
>>>     others
>>>     > so that I can complete the draft.
>>>
>>>     I wonder if this is the only remaining blocking issue for this draft.
>>>
>>>     We do not seem to have a strong consensus here.
>>>
>>>
>>>   Not sure why.  I am not aware of
>>>  anyone disagreeing with Rick on this point.
>>
>> Rick prefers option 1. In earlier email, I stated a preference for
>> option 2. That's why he posted this question to the WG.
>>
>> His question was posted on March 25. My reply yesterday, I believe,
>> was the first response. So there has been no WG response for the
>> past seven weeks -- no agreement nor objection.
>>
>>
>>>     Implementation guidance for option 2 could remain as simple as the
>>>     sentence you provide above, with a brief discussion of why ACL
>>>     comparison is challenging.
>>>
>>>     The draft can then permit implementers to choose between these options.
>>>
>>>
>>> I don't see the point in doing this.  If you allow #1,  then there is
>>> no point in doing the work for #2.  This is especially true since
>>> clients would have to deal with servers that implement #1, who are
>>> likely to  be the vast majority.
>>
>> Then the draft can either:
>>
>> - Not mention NVERIFY/VERIFY at all, since the relevant status code
>>   response is already prescribed in Section 18.15.4 of RFC 8881, or
>>
>> - Repeat the normative advice from 18.15.4, stating only that "if an NFS
>>   server implementation does not support comparing POSIX ACLs, the NFSv4
>>   NVERIFY and VERIFY operations are to return NFS4ERR_ATTRNOTSUPP; see
>>   Section 18.15.4 of RFC 8881.".
> Here's the para in 18.15.4 I think you are referring to?
> 
> In the case that a RECOMMENDED attribute is specified in the NVERIFY
>    operation and the server does not support that attribute for the file
>    system object, the error NFS4ERR_ATTRNOTSUPP is returned to the
>    client.
> 
> I read this as "if the attribute is not supported by the server" and not
> "if the attribute is not supported for VERIFY/NVERIFY".
> 
> I don't think a server can support the attribute for GETATTR/SETATTR,
> but then return NFS4ERR_ATTRNOTSUPP for VERIFY/NVERIFY of the
> attribute.

Fair enough.

So how should a server respond if a client includes an NVERIFY
operation in a COMPOUND and sets the bitmask bit that requests
comparison of a file's POSIX ACLs?


-- 
Chuck Lever