Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp5231702ybi; Tue, 30 Jul 2019 16:40:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqxC9zE+Dmmp0E4+0cg5ZbTC+0LXhmKOcbRnRFzhA9GajWjiHzFq9nG1D5SITobK8JEZAx73 X-Received: by 2002:a63:3281:: with SMTP id y123mr108474255pgy.72.1564530043580; Tue, 30 Jul 2019 16:40:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564530043; cv=none; d=google.com; s=arc-20160816; b=Diwll8jzUpTmcY7X20EzCL6MDOdbxwKWwhFpudkMe+8CUkjJK5Q3Ttz9uemTSpucui HBVJbz4gePqnAuC2bq4EqY1IO3vT23pP9J9F62vR6Ex3LqRkqq5WcpWVtG5L3sE+m6iZ /WU4fUwIPYSrXEHxzYXKntACOyF4sJuRzB4DEbszm92a4hliM+t7fGZBJKqKeaxnzxQT ABMfujyNRNIVhKdMnw1bfKO8H2EDc7gBN7SLIpFQ58CnAjLqkL/i+D4YUS+eppaoYa8y f6eQw7EK631fyOBgzYDWhNSqoyld0yP4GlQN6+O8ACknGBn1PKke6+uZdqrMd5KvxL4z gJJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=rIZoAKpV05RBhcm+/PGgnDhI0Ya1EwTUdiXVkORp1yg=; b=G04MmcMkLMwGPhBuy/ePBzPw1IMJO5NxhcHJRIo3bCeD3b6qMr40IySIHCrYMbH2EW 8zQtR2fk5VW4mTXWOjBeow1P7cO029yLtwTN2DoPng9hjoMmLpUamkrKcNWZLThW5lu0 eodGWvhouYzoMg19sZXiH1yivwPQt+0lWsLnPlFoluJdFu2/haX73obwQ89BGz4LY8ve 52DjQQuKytZKYistQIsi2NvWaFzwqkdzNS8U7vJ6cgcqaI9momsq3eYp5xwV3iquOEYm nRUtH6625mGYtyf6Unt6J+Zu8Gz5Y/xZJfSLFb0idZncZ1E7dzdMTDPx2ghoqeYkEyg3 F6ww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cu6si27970708pjb.102.2019.07.30.16.40.28; Tue, 30 Jul 2019 16:40:43 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726050AbfG3VJ7 (ORCPT + 99 others); Tue, 30 Jul 2019 17:09:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46110 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728214AbfG3VJ4 (ORCPT ); Tue, 30 Jul 2019 17:09:56 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 54E183082138 for ; Tue, 30 Jul 2019 21:09:56 +0000 (UTC) Received: from coeurl.usersys.redhat.com (ovpn-120-110.rdu2.redhat.com [10.10.120.110]) by smtp.corp.redhat.com (Postfix) with ESMTP id 374CA5D6A7; Tue, 30 Jul 2019 21:09:56 +0000 (UTC) Received: by coeurl.usersys.redhat.com (Postfix, from userid 1000) id C9FC0208C3; Tue, 30 Jul 2019 17:09:50 -0400 (EDT) From: Scott Mayhew To: steved@redhat.com Cc: linux-nfs@vger.kernel.org Subject: [nfs-utils PATCH RFC 0/2] add principal to the data being tracked by nfsdcld Date: Tue, 30 Jul 2019 17:09:48 -0400 Message-Id: <20190730210950.10545-1-smayhew@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Tue, 30 Jul 2019 21:09:56 +0000 (UTC) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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