> On Jun 2, 2018, at 9:37 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Fri, Jun 1, 2018 at 5:42 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> >>> On May 29, 2018, at 4:53 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>> >>>> On May 29, 2018, at 4:07 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>>> >>>> On Fri, May 25, 2018 at 6:35 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> 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. Some combination of both approaches is necessary. They are complementary and can be applied together. I believe we have to change the way the client ID string is constructed. Even if mount.nfs is working perfectly, there are use cases where the client's address is not a good addition to the string; it can change over reboots, for example, which is bad for a persistent client ID. My patch changes the non-UCS to use the same raw components as the UCS (plus non-UCS still has to include the server address). I agree that we don't have a way of knowing how clientaddr= can be used, and that's why mount.nfs has been left the way it is for so long. I can't think of a reason clientaddr should point to another machine. Thus restricting it to just local addresses and ANY addresses seems like it would be OK to do. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
