Hey Olga- > On May 23, 2018, at 8:27 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Tue, May 22, 2018 at 6:36 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> The question of whether the provided callback address is >> valid is a different matter. "Is this user-provided >> address one of my local interfaces or _ANY?" and then >> either warn or fail the mount if not. > > clientaddr is advertised to the users for the callback information and > yet the code uses it to construct the client id string. To be clear, the only way the server knows about callback information is because nfs4_proc_setclientid constructs a cb_client4 argument to SETCLIENTID. The server treats client ID strings as opaque blobs, used only for comparison with other client ID strings. It does not matter that the non-uniform client ID string we construct happens to have random bogus crap in it, just as long as it is different random bogus crap as any other client. ;-) What matters is what goes in cb_client4. > It should > either not do so and acquire the IP information independently from > what was supplied The normal situation is that "clientaddr=" is not specified by the administrator. Rather it is constructed by mount.nfs and passed into the kernel with the other mount options. (At least in the past) the kernel could not determine the callback information by itself, which is why we have clientaddr= in the first place. I'm not sure from your original post why the admin was supplying clientaddr= . I got the impression that it was malicious, but maybe I am mistaken? Was there some problem with the clientaddr= being supplied by mount.nfs ? > or I think there should be a check on the user > supplied input. It's rare that an administrator would need to explicitly add clientaddr= on the command line. But some input validation is reasonable in the case where an admin (and not mount.nfs) has specified this address. > Would you support a patch that does the check and then (I'm making a > choice here) fails the mount if the check fails. I would need to know specifically what you have in mind for "the check". -- 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
