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? 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>
