linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Mayhew <smayhew@redhat.com>
To: steved@redhat.com
Cc: linux-nfs@vger.kernel.org
Subject: [nfs-utils PATCH RFC v2 0/4] add principal to the data being tracked by nfsdcld
Date: Thu,  8 Aug 2019 14:34:29 -0400	[thread overview]
Message-ID: <20190808183433.3557-1-smayhew@redhat.com> (raw)

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 adds support for a "GetVersion" upcall which allows nfsd
to determine the maximum message version that nfsdcld supports.  Right
now it's based on the value of CLD_UPCALL_VERSION from cld.h, but I was
thinking we may wish to add a command-line option (and an nfs.conf)
option to make it possible to use a lower version than
CLD_UPCALL_VERSION.  My thinking here is that an older nfsdcld daemon
won't be compatible with the new database schema... rather than worrying
about messing with downgrading the database, just use the command-line
option to make it behave like an older daemon.

The second patch adds handling for the v2 Cld_Create and Cld_GraceStart
upcalls, which can include the kerberos principal which we'll store
along with the client id string in the database.  Note that if we're
talking to an old kernel that does the v1 upcall, everything still works
(we just ignore the new columns in the database).

The third patch adds a tool for manipulating nfsdcld's database schema.
It's mostly intended to be used to downgrade the database in the
(hopefully rare) event that an admin would want to downgrade nfsdcld.
It also provides the ability for fixing broken recovery table names
(which nfsdcld also fixes automatically) as well as the ability to print
the contents of the database.

The final patch updates the nfsdcld man page.

Questions:
1. Why do we have a copy of cld.h in support/include?  It seems
unnecessary... maybe we should get rid of it so that we're always
using the cld.h from the kernel headers?
2. Should there be a command line option to allow nfsdcld to advertise a
lower upcall version to nfsd in the GetVersion upcall reply?

Changes since v1:
- added a tool for manipulating nfsdcld's sqlite database schema
- updated the nfsdcld man page

Scott Mayhew (4):
  nfsdcld: add a "GetVersion" upcall
  nfsdcld: add support for upcall version 2
  Add a tool for manipulating the nfsdcld sqlite database schema.
  nfsdcld: update nfsdcld.man

 configure.ac                    |   1 +
 support/include/cld.h           |  37 ++++-
 tools/Makefile.am               |   4 +
 tools/clddb-tool/Makefile.am    |  13 ++
 tools/clddb-tool/clddb-tool.man |  83 ++++++++++
 tools/clddb-tool/clddb-tool.py  | 261 ++++++++++++++++++++++++++++++++
 utils/nfsdcld/cld-internal.h    |  13 +-
 utils/nfsdcld/nfsdcld.c         | 140 ++++++++++++++---
 utils/nfsdcld/nfsdcld.man       |  32 +++-
 utils/nfsdcld/sqlite.c          | 238 ++++++++++++++++++++++++-----
 utils/nfsdcld/sqlite.h          |   2 +
 11 files changed, 755 insertions(+), 69 deletions(-)
 create mode 100644 tools/clddb-tool/Makefile.am
 create mode 100644 tools/clddb-tool/clddb-tool.man
 create mode 100644 tools/clddb-tool/clddb-tool.py

-- 
2.17.2


             reply	other threads:[~2019-08-08 18:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-08 18:34 Scott Mayhew [this message]
2019-08-08 18:34 ` [nfs-utils PATCH RFC v2 1/4] nfsdcld: add a "GetVersion" upcall Scott Mayhew
2019-08-08 18:34 ` [nfs-utils PATCH RFC v2 2/4] nfsdcld: add support for upcall version 2 Scott Mayhew
2019-08-08 18:34 ` [nfs-utils PATCH RFC v2 3/4] Add a tool for manipulating the nfsdcld sqlite database schema Scott Mayhew
2019-08-08 18:34 ` [nfs-utils PATCH RFC v2 4/4] nfsdcld: update nfsdcld.man Scott Mayhew

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190808183433.3557-1-smayhew@redhat.com \
    --to=smayhew@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).