On Fri, Aug 11, 2023 at 10:28 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. This spec wording that it's required to implement but not required to use makes me ask why is it a requirement at all. Anyway... > > 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 today. > > > Incidentally, has anyone tried doing this with sec=krb5 in the current > > code? I'm not sure I fully understand your question but yes the COPY would work over a sec=krb5* mount. What is not there is fulfillment of the requirement to make sure that the client does COPY_NOTIFY over sec=krb5p gssv3 regardless what mount flavor was used originally. > Does it actually work? I don't see any place where we return > > nfserr_partner_no_auth, That's because initial implementation followed the spec wording that it is allowed to use auth_sys and not enforce gssv3. > so I wonder if we need to fix up the s2s COPY > > authentication and error handling? Yes the server would need to be change to enforce several things with regards to the COPY_NOTIFY and inter-server copy processing in general. > > 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? Yes and no. The fact that COPY_NOTIFY needs to be done over krb5p to insure privacy/integrity of passing the structured privilege. But then in order to use the structured privilege a new operation is used GSSv3_create which makes use of that. this operation must done with gss privacy. TLS is not a GSS protocol so underneath the only choice is krb5(p). You COULD layer gssv3 over TLS but I'm not sure what would be the point of that. So I think the real answer is:"no" we can't use TLS here. Or need to update the spec with a new way of doing "inter" copy security over TLS. > > > > 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>
