On Fri, Aug 11, 2023 at 10:42 AM Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Fri, Aug 11, 2023 at 10:23 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > 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 do still have Andy's gssv3 implementation patches, but it looks like it's been longer than I thought since I last rebased them. They apply cleanly to Linux 5.0, but not 5.1. I'll see what it takes to get them up to date. Anna > > I'd like to address some other questions later as I'm out of the office today. > > > Incidentally, has anyone tried doing this with sec=krb5 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=mtls 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@xxxxxxxxxx>
