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