Re: [nfsv4] Comments on minutes of wg meeting at IETF114

[Rick Macklem <[e-mail]>]

Chuck Lever III <[e-mail]> wrote:
>> On Sep 13, 2022, at 7:09 PM, Rick Macklem <[e-mail]> wrote:
>>
>> Chuck Lever III wrote:
>>> David Noveck wrote:
>> [stuff snipped to just comments related to FreeBSD/me]
>>
>>>> Let me give people some background.  Chuck objected to the
>>>> treatment of SECINFO in some earlier security-0x draft.  He thought it
>>>> was to complicated so we agreed that he would publish his approach, 
>>>>as he did in rpc- tls-pseudoflavors and I  would refer to that in the next
>>>> security draft.
>>>>
>>>> Now it appears that Chuck has changed his mind and I'd appreciate
>>>> knowing why<http://why.ch/>.
>>>
>>> Rick told me he is not going to implement it.
>> This statement sounds somewhat misleading, although true.
>> I do not see the FreeBSD client implementing pseudo-flavors
>> because it does not use Secinfo/SecinfoNoName and I doubt
>> it ever will.
>> --> It just considers NFS4ERR_WRONGSEC to be a fatal error
>>      that it maps to EACCES.
>>
>> The FreeBSD NFSv4 server could easily implement pseudo-flavors.
>> I was just waiting to see if there was a consensus that it was
>> the correct way to go.  I'll admit I do not see that consensus
>> at this time.
>
>Rick made this comment to me in private e-mail last March (don't
>worry, nothing embarrassing!):
>
>> Since NFSv4 has no way of acquiring the pseudoflavors before doing
>> ExchangeID..., I'll admit I don't see the pseuodflavors that useful.
>> I think cases where the security requirements for a given client changes
>> at server file system boundaries as fairly rare.
>
>I concluded based on that that Rick is not interested in
>implementing the mechanisms proposed in rpc-tls-pseudoflavor
>for FreeBSD at all. The mechanism does not add value for the
>use cases commonly deployed on FreeBSD NFS systems.

For the above, I was wearing my "client implementor hat".
It is true that a Secinfo like operation that could be performed
before ExchangeID/CreateSession might be more useful for the
FreeBSD client (but not enough to bother proposing it as
extension;-)

For the FreeBSD NFSv4 server, it is possible for the
security requirements to change on server file system
boundaries but, as above, I doubt that will be a common
case.

rick

--
Chuck Lever



_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4