linux-kernel - Re: [PATCH v3 2/3] fs: fuse: add backing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAC1kPDPWag5oaZH62YbF8c=g7dK2_AbFfYMK7EzgcegDHL829Q@mail.gmail.com>
Date: Sun, 11 May 2025 17:55:52 +0800
From: Chen Linxuan <chenlinxuan@...ontech.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Chen Linxuan <chenlinxuan@...ontech.com>, Amir Goldstein <amir73il@...il.com>, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/3] fs: fuse: add backing_files control file

On Fri, May 9, 2025 at 10:59 PM Miklos Szeredi <miklos@...redi.hu> wrote:

> Right.  But I'm not asking you to implement this, just thinking about
> an interface that is generic enough to cover past and possible future
> cases.

I am not very familiar with the existing features in the kernel and
their development directions.
For example, I do know about the SCM_RIGHTS functionality,
but if you hadn't mentioned it here,
I wouldn't have realized that they are essentially addressing the same
kind of problem.

I don't think I currently have enough expertise to design an interface
that could even account for future cases, but I will give it a try.

I noticed that the current extended attribute names already use the
namespace.value format.
Perhaps we could reuse this naming scheme and extend it to support
features like nested namespaces.

For instance, in a situation like this:

A fixed file 0 in an io_uring is a FUSE fd.
This FUSE fd belongs to FUSE connection 64.
This FUSE fd has a backing file.
This backing file is actually provided by mnt_id=36.

Running getfattr -m '-' /proc/path/to/the/io_uring/fd could return
something like:

io_uring.fixed_files.0.fuse.conn="64"
io_uring.fixed_files.0.fuse.backing_file.mnt_id="36"
io_uring.fixed_files.0.fuse.backing_file.path="/path/to/real/file"

Here, the mnt_id is included because I believe
resolving /path/to/real/file in user space might be a relatively complex task.
Providing this attribute could make it easier for tools like lsof to work with.

Additionally, the reason I am working on this is that
I want to make FUSE's passthrough functionality work for non-privileged users.

Someone on the mailing list asked why passthrough requires privileges before:
https://lore.kernel.org/all/CAOYeF9V_FM+0iZcsvi22XvHJuXLXP6wUYPwRYfwVFThajww9YA@mail.gmail.com/#t
In response, I submitted a patch that includes documentation explaining this:
https://lore.kernel.org/all/20250507-fuse-passthrough-doc-v2-0-ae7c0dd8bba6@uniontech.com/

Perhaps we could start by discussing that patch.