> On Mar 23, 2023, at 1:57 PM, Steve Dickson <steved@xxxxxxxxxx> wrote: > > > > On 3/21/23 7:52 AM, Jeff Layton wrote: >> On Mon, 2023-03-20 at 10:35 -0400, Chuck Lever wrote: >>> Hi Steve- >>> >>> This is server-side support for RPC-with-TLS, to accompany similar >>> support in the Linux NFS client. This implementation can support >>> both the opportunistic use of transport layer security (it will be >>> used if the client cares to) and the required use of transport >>> layer security (the server requires the client to use it to access >>> a particular export). >>> >>> Without any other user space componentry, this implementation will >>> be able to handle clients that request the use of RPC-with-TLS. To >>> support security policies that restrict access to exports based on >>> the client's use of TLS, modifications to exportfs and mountd are >>> needed. These can be found here: >>> >>> git://git.linux-nfs.org/projects/cel/nfs-utils.git >>> >>> They include an update to exports(5) explaining how to use the new >>> "xprtsec=" export option. >>> >>> The kernel patches, along with the the handshake upcall, are carried >>> in the topic-rpc-with-tls-upcall branch available from: >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git >>> >>> This was posted under separate cover. >>> >>> --- >>> >>> Chuck Lever (4): >>> libexports: Fix whitespace damage in support/nfs/exports.c >>> exports: Add an xprtsec= export option >>> exportfs: Push xprtsec settings to the kernel >>> exports.man: Add description of xprtsec= to exports(5) >>> >>> >>> support/export/cache.c | 15 ++++++ >>> support/include/nfs/export.h | 6 +++ >>> support/include/nfslib.h | 14 +++++ >>> support/nfs/exports.c | 100 ++++++++++++++++++++++++++++++++--- >>> utils/exportfs/exportfs.c | 1 + >>> utils/exportfs/exports.man | 45 +++++++++++++++- >>> 6 files changed, 172 insertions(+), 9 deletions(-) >>> >> Nice work, Chuck! This all looks pretty straightforward. I have a >> (minor) concern about potentially blocking nfsd threads for up to 20s in >> a handshake, but this seems like a good place to start. > Yes! But Will here be a V2 with the suggested changes? I've done the suggested updates in my private tree already, so I can post a refresh soon. > It would be good to get a new release with these patches > in before the upcoming Bakeathon. The concept and operation of xprtsec= is pretty new... would there be a problem if all this were to change significantly after community review? -- Chuck Lever