Re: NFS/TLS situation on Windows - Re: Why TLS and Kerberos are not useful for NFS security Re: [PATCH nfs-utils] exportfs: make "insecure" the default for all exports

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 20 May 2025 at 03:38, Rick Macklem <rick.macklem@xxxxxxxxx> wrote:
>
> On Mon, May 19, 2025 at 6:03 AM Lionel Cons <lionelcons1972@xxxxxxxxx> wrote:
> >
> > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@xxxxxxxxxxx.
> >
> >
> > On Thu, 15 May 2025 at 04:09, Rick Macklem <rick.macklem@xxxxxxxxx> wrote:
> > >
> > > On Wed, May 14, 2025 at 2:51 PM Martin Wege <martin.l.wege@xxxxxxxxx> wrote:
> > > What other clients are there out there? (Hummingbird's, now called
> > > OpenText's NFSv4.0 client. I was surprised to see it was still possible
> > > to buy it. And it probably can be put in the same category as the MacOS one.)
> >
> > Situation on Windows:
> > 1. OpenText NFSv4 client: We've talked to Opentext about TLS support,
> > and they do not know whether a market for NFS over TLS outside what
> > they call the "Linux bubble" will ever martialise. There is also risk,
> > both engineering and drastic performance degradation if the Windows
> > native TLS is used (this is a kernel driver, so only the Windows
> > native TLS can be used).
> > So this is not going to happen unless someone pays, and the
> > performance will not be great.
> >
> > 2. ms-nfs41-client NFSv4.2 client: I've talked to Roland Mainz, who is
> > working with Tigran Mkrtchyan on ms-nfs41-client (Windows NFSv4.2
> > client). Their RPC is based on libtirpc, and if steved-libtirpc gets
> > TLS support, then this can be easily ported. But Roland (didn't ask
> > Tigran yet) doesn't have time to implement TLS support in libtirpc.
> >
> > 3. Windows Server 20xx NFSv4.1 server: Other department went through a
> > cycle of meetings with Microsoft in 2024/2025, so far Microsoft wants
> > "market demand" (which doesn't seem to materialise), and cautions that
> > the performance might be below 50% of a similar SMB configuration,
> > because TLS is not considered to be a good match for network
> > filesystems.
> >
> > Summary:
> > Forget about NFS/TLS on Windows.
> Well, for #1 and #3 I'm not surprised and would agree.
> I would like to find a way forward for #2.
> I will take a look at the libtirpc sources and try and cobble to-gether
> a prototype using the OpenSSL libraries.

That would be awesome

>
> I am not sure how helpful that will be for Roland, but it might be a
> starting point. (It depends upon what Microsoft provides in the kernel
> w.r.t. TLS and whether the driver uses a libtirpc library built from sources.

If it works with steved-libtirpc on Linux, then it should work with
the libtirpc from ms-nfs41-client too.

Question is whether the openssl license is compatible to LGPL used by
ms-nfs41-client

>
> I do plan on posting to the mailing list for #2, since I did a short
> test drive of the driver.

Thank you



Lionel





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux