On Wed, Oct 20, 2021 at 12:37:08PM -0400, Olga Kornievskaia wrote: > On Wed, Oct 20, 2021 at 11:54 AM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > knfsd has supported server-to-server copy for a couple years (since > > 5.5). You have set a module parameter to enable it. I'm getting asked > > when we could turn that parameter on by default. > > > > I've got a couple vague criteria: one just general maturity, the other a > > security question: > > > > 1. General maturity: the only reports I recall seeing are from testers. > > Is anyone using this? Does it work for them? Do they find a benefit? > > Maybe we could turn it on by default in one distro (Fedora?) and promote > > it a little and see what that turns up? > > > > 2. Security question: with server-to-server copy enabled, you can send > > the server a COPY call with any random address, and the server will > > mount that address, open a file, and read from it. Is that safe? (Whoops, I forgot, there's no open, just reads. And I don't know how much actual protocol there is involved in the mount.) > How about adding a piece then on the server (a policy) that would only > control that? The concept behind the server-to-server was that servers > might have a private/fast network between them that they would want to > utilize. A more restrictive policy could be to only allow predefined > network space to do the COPY? I know that more work. But sound like > perhaps it might be something that provides more control to the > server. That sounds like a step backwards if you're trying to enable it by default. But in the case there's a special server-to-server network, the way to handle that is by configuring the source server to return addresses on that network in the cnr_source_server field of the COPY_NOTIFY reply, right? > But as Chuck pointed out perhaps the kerberos piece would make this > concern irrelevant. I don't think kerberos addresses this. (It may make increase the attack surface, in fact.) > > Normally we only mount servers that were chosen by root. Here we'll > > mount any random server that some client told us to. What's the worst > > that random server can do? Do we trust our xdr decoding? Can it DOS us > > by throwing the client's state recovery code into some loop with weird > > error returns? Etc. > > Client code has been modified to know about special copy stateids that > if the client gets BAD_STATEID it knows not to try to do recovery and > instead it errors back to the "application", it being nfsd. Good to know, thanks. What are the list of rpc calls that are made to the source server--is it just READ, or does it at least need to create a client and a session? Are there any other error handling paths that we wouldn't want to go down? Etc. --b. > > Maybe it's fine. I'm OK with some level of risk. I just want to make > > sure somebody's thought this through. > > > > There's also interest in allowing unprivileged NFS mounts, but I don't > > think we've turned that on yet, partly for similar reasons. This is a > > subset of that problem. > > > > --b.
