How does FSID_Override prevent handle guessing? You can take the inode portion of a handle, and wrap it in export ID and FSID that match an export you have access to. The open_by_handle_at system call will then happily access the file or directory. Good to know about recovery_fs_ng. We should take a look at that code and figure out if it makes any sense and either make it usable or discard it. Frank -----Original Message----- From: Martin Schwenke [mailto:martin@meltin.net] Sent: Wednesday, August 19, 2026 8:20 PM To: devel@lists.nfs-ganesha.org Cc: Frank Filz <ffilzlnx@mindspring.com>; purkaitabhinandan@gmail.com Subject: Re: [NFS-Ganesha-Devel] Re: Guidance: keeping `RecoveryRoot` inside an exported tree via a nested export with `Access_Type = None` On Wed, 19 Aug 2026 15:59:21 -0700, "Frank Filz" <ffilzlnx@mindspring.com> wrote:
One tiny caveat - Ganesha has no subtree checking for handles so handle guessing can be used to access files not intended to be visible.
We are planning to use FSID_Override=True to force per-export Filesystem_ID's into handles. We can then specify a unique Filesystem_ID per export to avoid this issue. We still need to understand the negatives connotations of doing this.
As to fs vs fs_ng, I'm insufficiently knowledgeable about the changes for ng so I can't offer much advice there.
If fs_ng works given testing, then that is probably the best way to go.
When I originally had to make this decision, I found comments in fs_ng indicating that it might be incomplete. These days, fs at least supports RecoveryBackendIPBased=True, so should be conceptually simpler to use. I'm obviously interested in further discussion of these ideas... :-) peace & happiness, martin