Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <e2b1210d-5b06-72bb-59c5-6b8b712fd2ec@redhat.com>
Date:   Wed, 20 Oct 2021 13:24:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.1.0
Subject: Re: server-to-server copy by default
Content-Language: en-US
To:     Chuck Lever III <chuck.lever@oracle.com>,
        Bruce Fields <bfields@fieldses.org>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Dai Ngo <dai.ngo@oracle.com>,
        Olga Kornievskaia <olga.kornievskaia@gmail.com>
References: <20211020155421.GC597@fieldses.org>
 <18E32DF5-3F1D-4C23-8C2F-A7963103CF8C@oracle.com>
From:   Steve Dickson <steved@redhat.com>
In-Reply-To: <18E32DF5-3F1D-4C23-8C2F-A7963103CF8C@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hey!

On 10/20/21 12:00, Chuck Lever III wrote:
> 
> 
>> 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?
> 
> I like the idea of enabling it in one of the technology
> preview distributions.
My thoughts on this... we can do this one of two ways.
either do a kernel patch to enable inter_copy_offload_enable
by default or I could have nfs-utils drop a nfsd.conf file in
/etc/modprobe.d/ enabling it.

The kernel patch is more of a commitment but the
nfs-utils change is easier to back out.

> 
> But wrt the maturity question, is the work finished? Or,
> perhaps a better question is do we have a minimum viable
> product here that can be enabled, or is more work needed
> to meet even that bar?
I've been testing it and it seems to be pretty solid.

Question, Olga mentioned Dia did a patch that eliminations
the (rsize*14) file size limit... Meaning the file has
to be greater that (rsize*14) for the SSC to happen.
Was that patch committed? I have not looked that hard
but I haven't found it...

> 
> One thing that I recall is missing is support for Kerberos
> in the server-to-server copy operation. Is that in plan,
> or deemed unimportant?
Personally I think we should make sure the technology
is stable before adding things on to it.. IMHO.

> 
> 
>> 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.
> 
> A basic question is what is in distribution QE test suites
> that could exercise this feature? Should upstream be tasked
> with providing any missing pieces (as part of, say, pynfs,
> or nfstests)?
As Olga pointed out... nfstests already has a test...

my two cents,

steved.

> 
> 
>> 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.
> 
> --
> Chuck Lever
> 
> 
>