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). Question: 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? Scott Mayhew (2): nfsdcld: add a "GetVersion" upcall nfsdcld: add support for upcall version 2 support/include/cld.h | 37 +++++- utils/nfsdcld/cld-internal.h | 13 +- utils/nfsdcld/nfsdcld.c | 140 +++++++++++++++++---- utils/nfsdcld/sqlite.c | 238 +++++++++++++++++++++++++++++------ utils/nfsdcld/sqlite.h | 2 + 5 files changed, 366 insertions(+), 64 deletions(-) -- 2.17.2
