linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH RFC 0/2] nfsd: add principal to the data being tracked by nfsdcld
@ 2019-07-30 21:08 Scott Mayhew
  2019-07-30 21:08 ` [PATCH RFC 1/2] nfsd: add a "GetVersion" upcall for nfsdcld Scott Mayhew
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Scott Mayhew @ 2019-07-30 21:08 UTC (permalink / raw)
  To: bfields, chuck.lever; +Cc: linux-nfs

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.  This is an initial
attempt at doing that.

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. 

Initially I had played with the idea of hanging a version number off
either the cld_net or nfsd_net structure, exposing that via a proc file,
and having the userspace daemon write the desired version number to the
proc file prior to opening the rpc_pipefs file.  That was potentially
problematic if nfsd was already trying to queue an upcall using a
version that nfscld didn't support... so I like the GetVersion upcall
idea better.  Another option might be to have different rpc_pipefs
files for the different message versions and decide which version to use
based on which pipefs file the daemon opens.

The second patch actually adds the v2 message, which adds the principal
(actually just the first 1024 bytes) to the Cld_Create upcall and to the 
Cld_GraceStart downcall (which is what loads the data in the
reclaim_str_hashtbl). I couldn't really figure out what the maximum length
of a kerberos principal actually is (looking at krb5.h the length field in
the struct krb5_data is an unsigned int, so I guess it can be pretty big).
I don't think the principal will be that large in practice, and even if
it is the first 1024 bytes should be sufficient for our purposes.

Scott Mayhew (2):
  nfsd: add a "GetVersion" upcall for nfsdcld
  nfsd: add support for upcall version 2

 fs/nfsd/nfs4recover.c         | 332 +++++++++++++++++++++++++++-------
 fs/nfsd/nfs4state.c           |   6 +-
 fs/nfsd/state.h               |   3 +-
 include/uapi/linux/nfsd/cld.h |  37 +++-
 4 files changed, 311 insertions(+), 67 deletions(-)

-- 
2.17.2


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-07-31 14:31 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-30 21:08 [PATCH RFC 0/2] nfsd: add principal to the data being tracked by nfsdcld Scott Mayhew
2019-07-30 21:08 ` [PATCH RFC 1/2] nfsd: add a "GetVersion" upcall for nfsdcld Scott Mayhew
2019-07-30 21:08 ` [PATCH RFC 2/2] nfsd: add support for upcall version 2 Scott Mayhew
2019-07-30 21:54 ` [PATCH RFC 0/2] nfsd: add principal to the data being tracked by nfsdcld J. Bruce Fields
2019-07-30 21:56   ` J. Bruce Fields
2019-07-31 12:11     ` Scott Mayhew
2019-07-31 12:07   ` Scott Mayhew
2019-07-31 14:31     ` J. Bruce Fields

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).