Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <b1ae55f1c835ea6b30089a9377ae67c40d43a0fc.camel@kernel.org>
In-Reply-To: <b1ae55f1c835ea6b30089a9377ae67c40d43a0fc.camel@kernel.org>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Fri, 11 Aug 2023 10:28:19 -0400
Message-ID: <CAN-5tyHejgLNPrF-bybFqrkiEvvFb+SZ9NHne9RiQ0kVwESd5A@mail.gmail.com>
Subject: Re: turning on s2s copy by default in knfsd
To:     Jeff Layton <jlayton@kernel.org>
Cc:     Chuck Lever <chuck.lever@oracle.com>, Dai Ngo <dai.ngo@oracle.com>,
        Dave Wysochanski <dwysocha@redhat.com>,
        Steve Dickson <steved@redhat.com>,
        Olga Kornieskaia <kolga@netapp.com>,
        linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Aug 11, 2023 at 10:23=E2=80=AFAM Jeff Layton <jlayton@kernel.org> w=
rote:
>
> Chuck and I were chatting yesterday about what it will take to make the
> inter_copy_offload_enable module option on by default, and I'd like to
> start working toward that end.
>
> I think what we want to aim for is to eventually deprecate the module
> option and have this "just work" when the conditions are right.
>
> It looks like main obstacle is this (from RFC7862 section 4.9):
>
>    NFSv4 clients and servers supporting the inter-server COPY operations
>    described in this section are REQUIRED to implement the mechanism
>    described in Section 4.9.1.1 and to support rejecting COPY_NOTIFY
>    requests that do not use the RPC security protocol (RPCSEC_GSS)
>    [RFC7861] with privacy.  If the server-to-server copy protocol is
>    based on ONC RPC, the servers are also REQUIRED to implement
>    [RFC7861], including the RPCSEC_GSSv3 "copy_to_auth",
>    "copy_from_auth", and "copy_confirm_auth" structured privileges.
>    This requirement to implement is not a requirement to use; for
>    example, a server may, depending on configuration, also allow
>    COPY_NOTIFY requests that use only AUTH_SYS.
>
>    If a server requires the use of an RPCSEC_GSSv3 copy_to_auth,
>    copy_from_auth, or copy_confirm_auth privilege and it is not used,
>    the server will reject the request with NFS4ERR_PARTNER_NO_AUTH.
>
> We don't (yet) have GSSv3 support, so we'd need to implement that in
> order to make this work right with krb5. Has anyone started looking at
> GSSv3?

Andy Adamson way back when implemented a draft gssv3 implementation
and I believe we still have those patches. Anna periodically have been
rebasing them but no more than that. I believe there might have been
even some patches for the copy piece but I believe those might be
lost. I'd have to dig around in my oldest laptop.

I'd like to address some other questions later as I'm out of the office tod=
ay.

> Incidentally, has anyone tried doing this with sec=3Dkrb5 in the current
> code? Does it actually work? I don't see any place where we return
> nfserr_partner_no_auth, so I wonder if we need to fix up the s2s COPY
> authentication and error handling?
>
> Another question: The v4.2 spec was written before the RPC over TLS
> spec. Should we aim to allow this to work by default if the client and
> both servers are using xprtsec=3Dmtls and are secured by the same CA?
>
> 1/ the client and servers are all using GSSv3 with krb5p (or some other
> encryption)
>
> ...or...
>
> 2/ the client and servers are all using mtls with certificates signed by
> the same CA
>
>
> ...I expect we'll probably be able to accomodate #2 before #1.
>
> Beyond that, we could allow for module or export option that still
> allows s2s copy to work and relaxes the above restrictions (to allow
> people to use it over plaintext with AUTH_SYS on "secure" networks).
>
> Anything I've overlooked here, or other thoughts?
>
> Cheers,
> --
> Jeff Layton <jlayton@kernel.org>