* Re: Public NFSv4 handle?
2024-02-13 20:28 ` Dan Shelton
@ 2024-02-13 20:42 ` Jeff Layton
2024-02-13 20:58 ` Trond Myklebust
2024-02-13 21:16 ` Chuck Lever III
2 siblings, 0 replies; 12+ messages in thread
From: Jeff Layton @ 2024-02-13 20:42 UTC (permalink / raw)
To: Dan Shelton; +Cc: Tom Talpey, Linux NFS Mailing List
On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote:
> On Fri, 9 Feb 2024 at 16:32, Jeff Layton <jlayton@kernel.org> 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 <dan.f.shelton@gmail.com> 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 <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Public NFSv4 handle?
2024-02-13 20:28 ` Dan Shelton
2024-02-13 20:42 ` Jeff Layton
@ 2024-02-13 20:58 ` Trond Myklebust
2024-02-14 6:12 ` Cedric Blancher
2024-02-13 21:16 ` Chuck Lever III
2 siblings, 1 reply; 12+ messages in thread
From: Trond Myklebust @ 2024-02-13 20:58 UTC (permalink / raw)
To: jlayton@kernel.org, dan.f.shelton@gmail.com
Cc: tom@talpey.com, linux-nfs@vger.kernel.org
On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote:
> [You don't often get email from dan.f.shelton@gmail.com. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Fri, 9 Feb 2024 at 16:32, Jeff Layton <jlayton@kernel.org> 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
> > > > <dan.f.shelton@gmail.com> 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
trond.myklebust@hammerspace.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Public NFSv4 handle?
2024-02-13 20:58 ` Trond Myklebust
@ 2024-02-14 6:12 ` Cedric Blancher
2024-02-15 17:25 ` Frank Filz
0 siblings, 1 reply; 12+ messages in thread
From: Cedric Blancher @ 2024-02-14 6:12 UTC (permalink / raw)
To: Trond Myklebust
Cc: jlayton@kernel.org, dan.f.shelton@gmail.com, tom@talpey.com,
linux-nfs@vger.kernel.org
On Tue, 13 Feb 2024 at 21:59, Trond Myklebust <trondmy@hammerspace.com> wrote:
>
> On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote:
> > [You don't often get email from dan.f.shelton@gmail.com. Learn why
> > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Fri, 9 Feb 2024 at 16:32, Jeff Layton <jlayton@kernel.org> 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
> > > > > <dan.f.shelton@gmail.com> 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 <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: Public NFSv4 handle?
2024-02-14 6:12 ` Cedric Blancher
@ 2024-02-15 17:25 ` Frank Filz
0 siblings, 0 replies; 12+ messages in thread
From: Frank Filz @ 2024-02-15 17:25 UTC (permalink / raw)
To: 'Cedric Blancher', 'Trond Myklebust'
Cc: jlayton, dan.f.shelton, tom, linux-nfs
> From: Cedric Blancher [mailto:cedric.blancher@gmail.com]
> On Tue, 13 Feb 2024 at 21:59, Trond Myklebust <trondmy@hammerspace.com>
> wrote:
> >
> > On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote:
> > > [You don't often get email from dan.f.shelton@gmail.com. Learn why
> > > this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > On Fri, 9 Feb 2024 at 16:32, Jeff Layton <jlayton@kernel.org> 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
> > > > > > <dan.f.shelton@gmail.com> 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 <cedric.blancher@gmail.com>
> [https://plus.google.com/u/0/+CedricBlancher/]
> Institute Pasteur
Frank Filz
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Public NFSv4 handle?
2024-02-13 20:28 ` Dan Shelton
2024-02-13 20:42 ` Jeff Layton
2024-02-13 20:58 ` Trond Myklebust
@ 2024-02-13 21:16 ` Chuck Lever III
2 siblings, 0 replies; 12+ messages in thread
From: Chuck Lever III @ 2024-02-13 21:16 UTC (permalink / raw)
To: Dan Shelton; +Cc: Jeff Layton, Tom Talpey, Linux NFS Mailing List
> On Feb 13, 2024, at 3:28 PM, Dan Shelton <dan.f.shelton@gmail.com> wrote:
>
> On Fri, 9 Feb 2024 at 16:32, Jeff Layton <jlayton@kernel.org> 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 <dan.f.shelton@gmail.com> 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
^ permalink raw reply [flat|nested] 12+ messages in thread