> On Feb 13, 2024, at 3:28 PM, Dan Shelton <dan.f.shelton@xxxxxxxxx> wrote: > > 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. > > 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
