On Wed, May 23, 2018 at 12:05 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > 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? In practice it was a simple misconfiguration on the part of the admin that input an incorrect address. Mistaken or malicious attempt will greatly interfere with a legitimate user. > Was there some problem > with the clientaddr= being supplied by mount.nfs ? The problem is that clientaddr is allowed to be specified by the user and have no checks before being used as an input to the client id content. >> 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. I guess not rare enough as it came up as a customer case. > But some input validation > is reasonable in the case where an admin (and not mount.nfs) > has specified this address. I believe so and that's what I'm trying to accomplish. >> 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". I will make another attempt at the check to include allowing for the 0.0.0.0 and whatever equivalent of it is in ipv6. -- 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
