I am in general concerned about turning on new features before basic ones work reliably. We’ve had enough different failures that we’ve backup up to NFS 3 for file systems with heavy use. We first tried turning off delegation. That helped a lot. But we just ran into a two different machine hung trying to lock Chome’s profile. (I sent a bit of information on that one previously.) We had to restart NFS on the server to fix it, and that caused us to lose a bunch of VMs. (That shouldn’t have happened. It looks like ESX misbehaved.) If I could turn off NFS4 locking I would. > On 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? > > 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. > > 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.
