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-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@xxxxxxxxxxxxxxx
