Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Scott Mayhew <smayhew@redhat.com>
To:     bfields@fieldses.org, chuck.lever@oracle.com
Cc:     simo@redhat.com, linux-nfs@vger.kernel.org
Subject: [PATCH v2 0/2] add hash of the kerberos principal to the data being tracked by nfsdcld
Date:   Mon,  9 Sep 2019 16:10:29 -0400
Message-Id: <20190909201031.12323-1-smayhew@redhat.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

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(-)

-- 
2.17.2