Re: [PATCH 1/1] nfs-utils: Add check of clientaddr argument

[Olga Kornievskaia <aglo@umich.edu>]

On Fri, Jun 1, 2018 at 5:42 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>> On May 29, 2018, at 4:53 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>>> On May 29, 2018, at 4:07 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
>>>
>>> On Fri, May 25, 2018 at 6:35 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>
>>>> I can think of legitimate cases where two unique NFSv4.0
>>>> clients having the same IP address might mount the same
>>>> server.
>>>>
>>>> - clientaddr=0.0.0.0, as mentioned above
>>>
>>> I think this should be prohibited. If this is used a way to signify to
>>> the server to no give out delegations, then there could be other means
>>> of doing so. Let's add a mount option 'nodeleg', client would send a
>>> valid callback info to the server but if the option is set, then it
>>> will not start a callback server. That would prevent the server from
>>> being able to establish a callback path (which is the same thing as
>>> sending 0.0.0.0).
>>
>> That introduces delays while the server is probing the client's
>> callback server. The spec specifically allows a client to send
>> 0.0.0.0 to signify that the server should not use callbacks.
>>
>> And mount.nfs has allowed that setting for a long time.
>>
>> IMO we have to continue to allow 0.0.0.0.
>
> Still thinking about this.
>
> Not using cl_ipaddr in the client ID string helps. I have a patch
> that does this.
>
> The question I've been wondering since the original post is "are there
> any other use cases where mount.nfs can't properly guess which address
> to provide?" That's why I was asking why your customer was using
> clientaddr.
>
> If we have confidence that mount.nfs is 100% reliable about choosing
> a good local address, except in the NAT case where we should just be
> disabling CB, then we could have mount.nfs strip off a user-supplied
> clientaddr and construct its own in all cases but the "clientaddr=
> 0.0.0.0" case (and it's IPv6 equivalent).

When you were saying that we want to enable the client to specify any
address that's available to it, I was thinking you were considering a
case of a multihome machine where the client wants to have normal nfs
connection go over one network but have the callback able to go over
another interface. I'm almost certain that was not the setup that the
customer was using but I can ask. In general, I don't think we really
know how the customers are using this because we only hear about
issues and not when things are just working.

So that I'm clear about what you saying: are you proposing two
different approaches. First is to do away with cl_ipaddr in client ID.
Then nothing is changed with the mount.nfs. Or second, we keep
cl_ipaddr as is in client ID and then instead change mount.nfs to
always choose the callback address for the user and only allow for
clientaddr=0.0.0.0 user input case?

Let me start with the 2nd one, I'm ok with it as long as we clearly
document it in man pages. As is right now I'm disappointed that
nowhere is the clientaddr=0.0.0.0 is documented (or even clearly
talked about in the spec). However, if there is at all of value having
a callback being on a different network, then I think instead, my
original approach that does the checks would be a better way to do (i
have a draft patch for it).

If we are changing how the client Id is constructed and not using the
cl_ipaddr, then I would like to know what would be used. But as long
as you feel like such in my view a major change doesn't do anything
bad, then I'm ok with it as it addresses the issue of user input to
mount.nfs mistakenly or maliciously causing problems.