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: <726db266-0ac4-e03e-9cc4-99e5b54b9349@redhat.com>
Date:   Thu, 21 Oct 2021 09:43:38 -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:     Olga Kornievskaia <olga.kornievskaia@gmail.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Dai Ngo <dai.ngo@oracle.com>
References: <20211020155421.GC597@fieldses.org>
 <CAN-5tyHuq3wmU1EThrfqv7Mq+F5o0BXXdkAnGXch_sYakv=eqA@mail.gmail.com>
 <0492823C-5F90-494E-8770-D0EC14130846@oracle.com>
 <20211020181512.GE597@fieldses.org>
 <EC5F0B99-7866-4AA6-BF2F-AB1A93C623DF@oracle.com>
From:   Steve Dickson <steved@redhat.com>
In-Reply-To: <EC5F0B99-7866-4AA6-BF2F-AB1A93C623DF@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10/20/21 15:04, Chuck Lever III wrote:
> 
> 
>> On Oct 20, 2021, at 2:15 PM, Bruce Fields <bfields@fieldses.org> wrote:
>>
>> On Wed, Oct 20, 2021 at 05:45:58PM +0000, Chuck Lever III wrote:
>>>> On Oct 20, 2021, at 12:37 PM, Olga Kornievskaia <olga.kornievskaia@gmail.com> wrote:
>>>>
>>>> On Wed, 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?
>>>>
>>>> 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.
>>>>
>>>> But as Chuck pointed out perhaps the kerberos piece would make this
>>>> concern irrelevant.
>>>
>>> I like the idea of having a server-side policy setting that
>>> controls whether s2sc is permitted, and maybe establishes a
>>> range of IP addresses allowed to be destination servers.
>>
>> Maybe, but:
>>
>> 	1) Couldn't you get something awfully close to that with
>> 	firewall configuration?
> 
> Not if the s2sc policy setting is on each export.
Is this level complication really necessary... I just
don't see why people would not want to make copies
on all exports faster.

Is not having this option a showstopper to enabling it?

> 
> 
>> 	2) I'm getting asked why server-side copy isn't on by default.
> 
> And your answer to that was "we haven't figured out how to
> guarantee security when it's enabled".
I'm thinking the servers will be behind a firewall
which by definition makes them secure.

Now if there is a malicious app throwing COPY calls
with rouge address behind the firewall is that
something we really need to protect from? The
network has already been compromised.

As Olga pointed out... clustered servers will have a
will have a very fast connection between them which
is something we should take advantage of... IMHO

steved.

> 
> 
>> 	So I guess the requirement to set inter_copy_offload_enable is
>> 	too much.  How does requiring more complicated configuration
>> 	answer that concern?
> 
> It answers the concern by letting local administrators choose
> to enable or disable s2sc based on their own security needs.
> 
> 
>> 	3) There's interest in allowing unprivileged NFS mounts.  That's
>> 	more of a security risk than this.  What's the client
>> 	maintainers' judgement about unprivileged NFS mounts?  Do they
>> 	think that would be safe to allow by default in distros?  If so,
>> 	then we're certainly fine here.
> 
> Unprivileged mounting seems like a different question to me.
> Related, possibly, but not the same. I'd rather leave that
> discussion to another thread.
> 
> 
> --
> Chuck Lever
> 
> 
>