On Mon, 2019-09-09 at 16:10 -0400, Scott Mayhew wrote: > At the spring bakeathon, Chuck suggested that we should store the > kerberos principal in addition to the client id string in nfsdcld. The > idea is to prevent an illegitimate client from reclaiming another > client's opens by supplying that client's id string. > > The first patch lays some groundwork for supporting multiple message > versions for the nfsdcld upcalls, adding fields for version and message > length to the nfsd4_client_tracking_ops (these fields are only used for > the nfsdcld upcalls and ignored for the other tracking methods), as well > as an upcall to get the maximum version supported by the userspace > daemon. > > The second patch actually adds the v2 message, which adds the sha256 hash > of the kerberos principal to the Cld_Create upcall and to the Cld_GraceStart > downcall (which is what loads the data in the reclaim_str_hashtbl). > > Changes since v1: > - use the sha256 hash of a principal instead of the principal itself > - prefer the cr_raw_principal (returned by gssproxy) if it exists, then > fall back to cr_principal (returned by both gssproxy and rpc.svcgssd) > > Scott Mayhew (2): > nfsd: add a "GetVersion" upcall for nfsdcld > nfsd: add support for upcall version 2 > > fs/nfsd/nfs4recover.c | 388 ++++++++++++++++++++++++++++------ > fs/nfsd/nfs4state.c | 6 +- > fs/nfsd/state.h | 3 +- > include/uapi/linux/nfsd/cld.h | 41 +++- > 4 files changed, 371 insertions(+), 67 deletions(-) > LGTM. -- Simo Sorce RHEL Crypto Team Red Hat, Inc
