Re: [PATCH 04/28] fuse: adapt FUSE_DEV_IOC_BACKING_{OPEN,CLOSE} to add new iomap devices

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Sep 19, 2025 at 11:54:39AM +0200, Amir Goldstein wrote:
> On Fri, Sep 19, 2025 at 9:14 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > On Thu, 18 Sept 2025 at 20:42, Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > On Thu, Sep 18, 2025 at 8:17 PM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > > > How about restricting the backing ids to RLIMIT_NOFILE?  The @end param
> > > > to idr_alloc_cyclic constrains them in exactly that way.
> > >
> > > IDK. My impression was that Miklos didn't like having a large number
> > > of unaccounted files, but it's up to him.
> >
> > There's no 1:1 mapping between a fuse instance and a "fuse server
> > process", so the question is whose RLIMIT_NOFILE?  Accounting to the
> > process that registered the fd would be good, but implementing it
> > looks exceedingly complex.  Just taking RLIMIT_NOFILE value from the
> > process that is doing the fd registering should work, I guess.

Or perhaps a static limit of 1024 for now, and if someone comes up with
a humongous filesystem that needs more, we can figure out how to support
that later.

Since we're already adding flag bits to the /dev/fuse file::private_data
for synchronous init, I guess we could expand that into a full struct so
that you could open /dev/fuse, ask for various config options, and then
apply them to the fuse_dev when it gets created?

> > There's still the question of unhiding these files.  Latest discussion
> > ended with lets create a proper directory tree for open files in proc.
> > I.e. /proc/PID/fdtree/FD/hidden/...

All the iomap backing files are block devices, perhaps we could put a
symlink in /sys/block/XXX/holders/ to something associated with the
fuse_mount?  Perhaps the s_bdi?

This is a more general problem, because there's no standard way to
figure out that a given bdev is an auxiliary device attached to a
multi-device filesystems (e.g. xfs realtime volume or external log).

The downsides are that "holders" is sysfs-happy and even symlinks
require a target kobject; and lsof doesn't know about holders.  But at
least it wouldn't be 100% invisible like it is now.

> Yes, well, fuse_backing_open() says:
> /* TODO: relax CAP_SYS_ADMIN once backing files are visible to lsof */
> So that's the reason I was saying there is no justification to
> relax this for FUSE_IOMAP as long as this issue is not resolved.
> 
> As Darrick writes, fuse4fs needs only 1 backing blockdev
> and other iomap fuse fs are unlikely to need more than a few
> backing blockdevs.

Until someone has a go at making btrfs-fuse fully functional.  But that
can be their problem. ;)

> So maybe, similar to max_stack_depth, we require the server to
> negotiate the max_backing_id at FUSE_INIT time.
> 
> We could allow any "reasonable" number without any capabilities
> and regardless of RLIMIT_NOFILE or we can account max_backing_id
> in advance for the user setting up the connection.
> 
> For backward compat (or for privileged servers) zero max_backing_id
> means unlimited (within the int32 range) and that requires
> CAP_SYS_ADMIN for fuse_backing_open() regardless of which
> type of backing file it is.
> 
> WDYT?

I think capping at 1024 now (or 256, or even 8) is fine for now, and we
can figure out the request protocol later when someone wants more.

Alternately, I wonder if there's a way to pin the fd that is used to
create the backing id so that the fuse server can't close it?  There's
probably no non-awful way to pin the fd table entry though.

--D

> Thanks,
> Amir.