Re: server-to-server copy by default

[Steve Dickson <steved@redhat.com>]

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@fieldses.org> 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.
>