Hello!
Do the Linux NFSv4 server and client support the NFS public handle?
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
?
On Thu, 25 Jan 2024 at 02:48, Dan Shelton <[email protected]> wrote:
>
> Hello!
>
> Do the Linux NFSv4 server and client support the NFS public handle?
>
> Dan
> --
> Dan Shelton - Cluster Specialist Win/Lin/Bsd
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
On 2/8/2024 7:19 PM, Dan Shelton wrote:
> ?
>
> On Thu, 25 Jan 2024 at 02:48, Dan Shelton <[email protected]> wrote:
>>
>> Hello!
>>
>> Do the Linux NFSv4 server and client support the NFS public handle?
Are you referring the the old WebNFS stuff? That was a v2/v3 thing,
and, I believe, only ever supported by Solaris.
Tom.
>>
>> Dan
>> --
>> Dan Shelton - Cluster Specialist Win/Lin/Bsd
>
>
>
On Thu, 2024-02-08 at 21:37 -0500, Tom Talpey wrote:
> On 2/8/2024 7:19 PM, Dan Shelton wrote:
> > ?
> >
> > On Thu, 25 Jan 2024 at 02:48, Dan Shelton <[email protected]> wrote:
> > >
> > > Hello!
> > >
> > > Do the Linux NFSv4 server and client support the NFS public handle?
>
> Are you referring the the old WebNFS stuff? That was a v2/v3 thing,
> and, I believe, only ever supported by Solaris.
>
One more try! I think my MUA was having issues this morning.
NFSv4.1 supports the PUTPUBFH op:
https://www.rfc-editor.org/rfc/rfc8881.html#name-operation-23-putpubfh-set-p
...but this op is only for backward compatibility. The Linux server
returns the rootfh (as it SHOULD).
--
Jeff Layton <[email protected]>
On Fri, 9 Feb 2024 at 16:32, Jeff Layton <[email protected]> wrote:
>
> On Thu, 2024-02-08 at 21:37 -0500, Tom Talpey wrote:
> > On 2/8/2024 7:19 PM, Dan Shelton wrote:
> > > ?
> > >
> > > On Thu, 25 Jan 2024 at 02:48, Dan Shelton <[email protected]> wrote:
> > > >
> > > > Hello!
> > > >
> > > > Do the Linux NFSv4 server and client support the NFS public handle?
> >
> > Are you referring the the old WebNFS stuff? That was a v2/v3 thing,
> > and, I believe, only ever supported by Solaris.
> >
>
> One more try! I think my MUA was having issues this morning.
>
> NFSv4.1 supports the PUTPUBFH op:
>
> https://www.rfc-editor.org/rfc/rfc8881.html#name-operation-23-putpubfh-set-p
>
> ...but this op is only for backward compatibility. The Linux server
> returns the rootfh (as it SHOULD).
No, I do not consider this "backward compatibility". The "public"
option is also intended for public servers, like package mirrors (e.g.
Debian), to have a better solution than http or ftp.
What does it take to implement a "public" export option?
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote:
> On Fri, 9 Feb 2024 at 16:32, Jeff Layton <[email protected]> wrote:
> >
> > On Thu, 2024-02-08 at 21:37 -0500, Tom Talpey wrote:
> > > On 2/8/2024 7:19 PM, Dan Shelton wrote:
> > > > ?
> > > >
> > > > On Thu, 25 Jan 2024 at 02:48, Dan Shelton <[email protected]> wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > Do the Linux NFSv4 server and client support the NFS public handle?
> > >
> > > Are you referring the the old WebNFS stuff? That was a v2/v3 thing,
> > > and, I believe, only ever supported by Solaris.
> > >
> >
> > One more try! I think my MUA was having issues this morning.
> >
> > NFSv4.1 supports the PUTPUBFH op:
> >
> > https://www.rfc-editor.org/rfc/rfc8881.html#name-operation-23-putpubfh-set-p
> >
> > ...but this op is only for backward compatibility. The Linux server
> > returns the rootfh (as it SHOULD).
>
> No, I do not consider this "backward compatibility". The "public"
> option is also intended for public servers, like package mirrors (e.g.
> Debian), to have a better solution than http or ftp.
>
> What does it take to implement a "public" export option?
>
Just someone with a will to write the patches for it (including a way to
properly test it). I don't have a problem with making the public fh
settable on the Linux server, but we'd need to hear more about how the
client implementation would work.
--
Jeff Layton <[email protected]>
On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote:
> [You don't often get email from [email protected]. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Fri, 9 Feb 2024 at 16:32, Jeff Layton <[email protected]> wrote:
> >
> > On Thu, 2024-02-08 at 21:37 -0500, Tom Talpey wrote:
> > > On 2/8/2024 7:19 PM, Dan Shelton wrote:
> > > > ?
> > > >
> > > > On Thu, 25 Jan 2024 at 02:48, Dan Shelton
> > > > <[email protected]> wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > Do the Linux NFSv4 server and client support the NFS public
> > > > > handle?
> > >
> > > Are you referring the the old WebNFS stuff? That was a v2/v3
> > > thing,
> > > and, I believe, only ever supported by Solaris.
> > >
> >
> > One more try! I think my MUA was having issues this morning.
> >
> > NFSv4.1 supports the PUTPUBFH op:
> >
> > https://www.rfc-editor.org/rfc/rfc8881.html#name-operation-23-putpubfh-set-p
> >
> > ...but this op is only for backward compatibility. The Linux server
> > returns the rootfh (as it SHOULD).
>
> No, I do not consider this "backward compatibility". The "public"
> option is also intended for public servers, like package mirrors
> (e.g.
> Debian), to have a better solution than http or ftp.
>
PUTPUBFH offers no extra security features over PUTROOTFH. It is
literally just a way to offer a second point of entry into the same
exported filesystem.
A more modern approach would be to create 2 containers on the same
host: one that shares the full namespace to be exported, and one that
shares only the bits of the namespace that are considered "public".
That approach requires no extra patches or customisation to existing
kernels.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
> On Feb 13, 2024, at 3:28 PM, Dan Shelton <[email protected]> wrote:
>
> On Fri, 9 Feb 2024 at 16:32, Jeff Layton <[email protected]> wrote:
>>
>> On Thu, 2024-02-08 at 21:37 -0500, Tom Talpey wrote:
>>> On 2/8/2024 7:19 PM, Dan Shelton wrote:
>>>> ?
>>>>
>>>> On Thu, 25 Jan 2024 at 02:48, Dan Shelton <[email protected]> wrote:
>>>>>
>>>>> Hello!
>>>>>
>>>>> Do the Linux NFSv4 server and client support the NFS public handle?
>>>
>>> Are you referring the the old WebNFS stuff? That was a v2/v3 thing,
>>> and, I believe, only ever supported by Solaris.
>>>
>>
>> One more try! I think my MUA was having issues this morning.
>>
>> NFSv4.1 supports the PUTPUBFH op:
>>
>> https://www.rfc-editor.org/rfc/rfc8881.html#name-operation-23-putpubfh-set-p
>>
>> ...but this op is only for backward compatibility. The Linux server
>> returns the rootfh (as it SHOULD).
>
> No, I do not consider this "backward compatibility". The "public"
> option is also intended for public servers, like package mirrors (e.g.
> Debian), to have a better solution than http or ftp.
>
> What does it take to implement a "public" export option?
For starters, I'd like to see a less nebulous user story that
explains why NFSD's PUTPUBFH operation is not adequate.
Unauthenticated clients can already mount an NFSv4 server's
psuedoroot via a well-known path ("/") and descend into any
publicly-accessible exported directory. That is typically
sufficient for streaming servers, package mirrors, and many
other kinds of distribution services.
Can you explain what else is needed?
--
Chuck Lever
On Tue, 13 Feb 2024 at 21:59, Trond Myklebust <[email protected]> wrote:
>
> On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote:
> > [You don't often get email from [email protected]. Learn why
> > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Fri, 9 Feb 2024 at 16:32, Jeff Layton <[email protected]> wrote:
> > >
> > > On Thu, 2024-02-08 at 21:37 -0500, Tom Talpey wrote:
> > > > On 2/8/2024 7:19 PM, Dan Shelton wrote:
> > > > > ?
> > > > >
> > > > > On Thu, 25 Jan 2024 at 02:48, Dan Shelton
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Do the Linux NFSv4 server and client support the NFS public
> > > > > > handle?
> > > >
> > > > Are you referring the the old WebNFS stuff? That was a v2/v3
> > > > thing,
> > > > and, I believe, only ever supported by Solaris.
> > > >
> > >
> > > One more try! I think my MUA was having issues this morning.
> > >
> > > NFSv4.1 supports the PUTPUBFH op:
> > >
> > > https://www.rfc-editor.org/rfc/rfc8881.html#name-operation-23-putpubfh-set-p
> > >
> > > ...but this op is only for backward compatibility. The Linux server
> > > returns the rootfh (as it SHOULD).
> >
> > No, I do not consider this "backward compatibility". The "public"
> > option is also intended for public servers, like package mirrors
> > (e.g.
> > Debian), to have a better solution than http or ftp.
> >
>
> PUTPUBFH offers no extra security features over PUTROOTFH. It is
> literally just a way to offer a second point of entry into the same
> exported filesystem.
Right. It doesn't expose your "private" filesystem hierarchy.
>
> A more modern approach would be to create 2 containers on the same
> host: one that shares the full namespace to be exported, and one that
> shares only the bits of the namespace that are considered "public".
> That approach requires no extra patches or customisation to existing
> kernels.
Oh for god's sake. Please don't call "containers" a "modern approach".
It's just a sad waste of resources, aside from the other shitload of
problems they cause.
Also in real life, we frog-eating backwards savages here in Europe do
not have so many public IPv4 addresses available to put everything
into containers, and changing everything to IPv6-only networks will
take another 2 or 3 decades here.
Ced
--
Cedric Blancher <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
> From: Cedric Blancher [mailto:[email protected]]
> On Tue, 13 Feb 2024 at 21:59, Trond Myklebust <[email protected]>
> wrote:
> >
> > On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote:
> > > [You don't often get email from [email protected]. Learn why
> > > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > On Fri, 9 Feb 2024 at 16:32, Jeff Layton <[email protected]> wrote:
> > > >
> > > > On Thu, 2024-02-08 at 21:37 -0500, Tom Talpey wrote:
> > > > > On 2/8/2024 7:19 PM, Dan Shelton wrote:
> > > > > > ?
> > > > > >
> > > > > > On Thu, 25 Jan 2024 at 02:48, Dan Shelton
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > Do the Linux NFSv4 server and client support the NFS public
> > > > > > > handle?
> > > > >
> > > > > Are you referring the the old WebNFS stuff? That was a v2/v3
> > > > > thing, and, I believe, only ever supported by Solaris.
> > > > >
> > > >
> > > > One more try! I think my MUA was having issues this morning.
> > > >
> > > > NFSv4.1 supports the PUTPUBFH op:
> > > >
> > > > https://www.rfc-editor.org/rfc/rfc8881.html#name-operation-23-putp
> > > > ubfh-set-p
> > > >
> > > > ...but this op is only for backward compatibility. The Linux
> > > > server returns the rootfh (as it SHOULD).
> > >
> > > No, I do not consider this "backward compatibility". The "public"
> > > option is also intended for public servers, like package mirrors
> > > (e.g.
> > > Debian), to have a better solution than http or ftp.
> > >
> >
> > PUTPUBFH offers no extra security features over PUTROOTFH. It is
> > literally just a way to offer a second point of entry into the same
> > exported filesystem.
Do any clients even provide a mechanism to mount using PUTPUBFH?
> Right. It doesn't expose your "private" filesystem hierarchy.
There are ways to avoid exposing the private filesystem hierarchy. I have used bind mounts in the past and some servers may allow specifying the pseudo path for exports to hide the filesystem hierarchy.
> > A more modern approach would be to create 2 containers on the same
> > host: one that shares the full namespace to be exported, and one that
> > shares only the bits of the namespace that are considered "public".
> > That approach requires no extra patches or customisation to existing
> > kernels.
>
> Oh for god's sake. Please don't call "containers" a "modern approach".
> It's just a sad waste of resources, aside from the other shitload of problems they
> cause.
> Also in real life, we frog-eating backwards savages here in Europe do not have
> so many public IPv4 addresses available to put everything into containers, and
> changing everything to IPv6-only networks will take another 2 or 3 decades
> here.
There are ways to do it without containers, though a container gives an additional level of security.
> Cedric Blancher <[email protected]>
> [https://plus.google.com/u/0/+CedricBlancher/]
> Institute Pasteur
Frank Filz