> From: Cedric Blancher [mailto:cedric.blancher@xxxxxxxxx] > On Tue, 13 Feb 2024 at 21:59, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> > wrote: > > > > On Tue, 2024-02-13 at 21:28 +0100, Dan Shelton wrote: > > > [You don't often get email from dan.f.shelton@xxxxxxxxx. Learn why > > > this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > > > On Fri, 9 Feb 2024 at 16:32, Jeff Layton <jlayton@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur Frank Filz
