mbox series

[v1,0/4] nfs-utils changes for RPC-with-TLS server

Message ID 167932279970.3437.7130911928591001093.stgit@manet.1015granger.net (mailing list archive)
Headers show
Series nfs-utils changes for RPC-with-TLS server | expand

Message

Chuck Lever March 20, 2023, 2:35 p.m. UTC
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(-)

--
Chuck Lever

Comments

Jeff Layton March 21, 2023, 11:52 a.m. UTC | #1
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.
Steve Dickson March 23, 2023, 5:57 p.m. UTC | #2
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?

It would be good to get a new release with these patches
in before the upcoming Bakeathon.

steved.
Chuck Lever III March 23, 2023, 6:01 p.m. UTC | #3
> On Mar 23, 2023, at 1:57 PM, Steve Dickson <steved@redhat.com> 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
Steve Dickson March 24, 2023, 6:35 p.m. UTC | #4
On 3/23/23 2:01 PM, Chuck Lever III wrote:
> 
> 
>> On Mar 23, 2023, at 1:57 PM, Steve Dickson <steved@redhat.com> 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.
Fair enough.
> 
> 
>> 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?
Not a problem at all! I was just thinking about get the patches into
Fedora rawhide to get some testing...

steved.

> 
> --
> Chuck Lever
> 
>
Chuck Lever III March 24, 2023, 7:50 p.m. UTC | #5
> On Mar 24, 2023, at 2:35 PM, Steve Dickson <steved@redhat.com> wrote:
> 
> 
> 
> On 3/23/23 2:01 PM, Chuck Lever III wrote:
>>> On Mar 23, 2023, at 1:57 PM, Steve Dickson <steved@redhat.com> 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.
> Fair enough.
>>> 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?
> Not a problem at all! I was just thinking about get the patches into
> Fedora rawhide to get some testing...

To test, rawhide would need to have a ktls-utils package. Jeff and I
have discussed this ... he's volunteered to pull it in when netdev
has finally blessed the kernel/netlink pieces of this stack.

--
Chuck Lever