From patchwork Thu Aug 8 18:34:29 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Scott Mayhew X-Patchwork-Id: 11084633 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0BC881395 for ; Thu, 8 Aug 2019 18:34:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0047028B8B for ; Thu, 8 Aug 2019 18:34:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E618128B83; Thu, 8 Aug 2019 18:34:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 10EA928B83 for ; Thu, 8 Aug 2019 18:34:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733248AbfHHSee (ORCPT ); Thu, 8 Aug 2019 14:34:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33190 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725535AbfHHSee (ORCPT ); Thu, 8 Aug 2019 14:34:34 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2CCFE30C3A1F for ; Thu, 8 Aug 2019 18:34:34 +0000 (UTC) Received: from coeurl.usersys.redhat.com (ovpn-121-91.rdu2.redhat.com [10.10.121.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id 13E0A19C69; Thu, 8 Aug 2019 18:34:34 +0000 (UTC) Received: by coeurl.usersys.redhat.com (Postfix, from userid 1000) id B439E20AAD; Thu, 8 Aug 2019 14:34:33 -0400 (EDT) From: Scott Mayhew 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 Message-Id: <20190808183433.3557-1-smayhew@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Thu, 08 Aug 2019 18:34:34 +0000 (UTC) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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