7:57 p.m.
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(a)lists.nfs-ganesha.org
Cc: Frank Filz <ffilzlnx(a)mindspring.com>; purkaitabhinandan(a)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(a)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