I don’t think it’s a common operation. But there’s enough going on that it’s hard to be sure. > On Nov 1, 2021, at 3:25 PM, Steve Dickson <steved@xxxxxxxxxx> wrote: > > Hello, > > On 11/1/21 14:22, Charles Hedrick wrote: >> 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. > This is the reason I was hopping not make this a global switch > but a per export switch... > > Question... Do you do many server to server copies in your world? > Meaning a client coping from one server to another? > > steved. > >>> 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. >
