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 <[email protected]>
On Fri, Aug 11, 2023 at 10:23 AM Jeff Layton <[email protected]> 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'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 <[email protected]>