From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Olga Kornievskaia <olga.kornievskaia@gmail.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Dai Ngo <dai.ngo@oracle.com>, Steve Dickson <steved@redhat.com>
Subject: Re: server-to-server copy by default
Date: Wed, 20 Oct 2021 14:15:12 -0400 [thread overview]
Message-ID: <20211020181512.GE597@fieldses.org> (raw)
In-Reply-To: <0492823C-5F90-494E-8770-D0EC14130846@oracle.com>
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?
2) I'm getting asked why server-side copy isn't on by default.
So I guess the requirement to set inter_copy_offload_enable is
too much. How does requiring more complicated configuration
answer that concern?
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.
--b.
next prev parent reply other threads:[~2021-10-20 18:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 15:54 server-to-server copy by default J. Bruce Fields
2021-10-20 16:00 ` Chuck Lever III
2021-10-20 16:33 ` Olga Kornievskaia
2021-10-20 19:03 ` dai.ngo
2021-10-20 20:29 ` Bruce Fields
2021-10-21 5:00 ` dai.ngo
2021-10-21 14:02 ` Bruce Fields
2021-10-22 6:34 ` dai.ngo
2021-10-22 12:58 ` Bruce Fields
2021-11-01 17:37 ` dai.ngo
2021-11-01 19:33 ` Bruce Fields
2021-11-01 19:55 ` dai.ngo
2021-10-20 17:24 ` Steve Dickson
2021-10-20 17:51 ` Chuck Lever III
2021-10-20 16:37 ` Olga Kornievskaia
2021-10-20 17:45 ` Chuck Lever III
2021-10-20 18:15 ` Bruce Fields [this message]
2021-10-20 19:04 ` Chuck Lever III
2021-10-21 13:43 ` Steve Dickson
2021-10-21 13:56 ` Bruce Fields
2021-10-21 14:13 ` Bruce Fields
2021-10-21 14:22 ` Trond Myklebust
2021-10-21 14:38 ` bfields
2021-10-20 18:00 ` J. Bruce Fields
2021-11-01 18:22 ` Charles Hedrick
2021-11-01 19:25 ` Steve Dickson
2021-11-01 19:44 ` Charles Hedrick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211020181512.GE597@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=olga.kornievskaia@gmail.com \
--cc=steved@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox