Re: [PATCH v1 0/2] RFC: Extend fuse-passthrough to directories

[Joanne Koong <joannelkoong@gmail.com>]

On Tue, Jun 17, 2025 at 3:15 PM Paul Lawrence <paullawrence@google.com> wrote:
>
> This is the first part of a much larger patch set that would allow a directory
> to be marked ‘passthrough’. At a high level, the fuse daemon can return an
> optional extra argument to FUSE_LOOKUP that contains an fd. Extra fields are
> added to the fuse_dentry, fuse_inode and fuse_file structs to have a backing
> path, inode and file respectively. When fuse is performing an operation, it will
> check for the existence of a backing object and if it exists forward the
> operation to the backing object.
>
> These two patches add the core infrastructure, handling of the extra argument
> response to lookup, and forwarding open, flush and close to the backing file.
> This is sufficient to validate the concept.
>
> The questions I have:
>
> * Is this something that interests the fuse maintainers and community?
> * Is this approach the correct one?
> * (if we agree yes to 1 & 2) Detailed analysis of the patches for errors.
>
> A few observations:
>
> I have matched backing objects to their fuse objects. Currently fuse passthrough
> puts a backing file into the fuse inode. I’m not quite sure why this was done -
> it seems to have been a very late change in the passthrough patch sets which
> happened without comment. It does not really make sense for full directory
> passthrough since unopened inodes still need to have backing inodes. The one
> advantage I can see is that it reduces the number of opens/closes of the backing
> file. However, this may also be a disadvantage - it moves closes, in particular,
> to an arbitrary point when the inode is flushed from cache.
>
> Backing operations need to happen in the context of the daemon, not the caller.
> (I am a firm believer of this principle.) This is not yet implemented, and is
> not (currently, and unfortunately) the way Android uses passthough. It is not
> hard to do, and if these patches are otherwise acceptable, will be added.
>
> There was a long discussion about the security issues of using an fd returned
> from the fuse daemon in the context of fuse passthrough, and the end solution
> was to use an ioctl to set the backing file. I have used the previously-rejected
> approach of passing the fd in a struct in the fuse_daemon response. My defense
> of this approach is
>
> * The fd is simply used to pull out the path and inode
> * All operations are revalidated
> * Thus there is no risk even if a privileged process with a protected fd is
> tricked into passing that fd back in this structure.
>
> I’m sure we will discuss this at length if this patch set is otherwise deemed
> valuable, and I am certainly not wedded to this approach.
>
> I have written tests to validate this approach using tools/testing/selftests. I
> don’t want this patch set to get derailed by a discussion of the way I wrote the
> tests, so I have not included them. I am very open to any and every suggestion
> as to how (and where) tests should be written for these patches.
>
> Paul Lawrence (2):
>   fuse: Add backing file option to lookup
>   fuse: open/close backing file
>
>  fs/fuse/Kconfig           |  13 +++++
>  fs/fuse/Makefile          |   1 +
>  fs/fuse/backing.c         |  97 ++++++++++++++++++++++++++++++++
>  fs/fuse/dev.c             |  14 +++++
>  fs/fuse/dir.c             | 108 +++++++++++++++++++++++++-----------
>  fs/fuse/file.c            |  34 ++++++++----
>  fs/fuse/fuse_i.h          |  61 +++++++++++++++++++-
>  fs/fuse/inode.c           | 114 ++++++++++++++++++++++++++++++++++----
>  include/uapi/linux/fuse.h |   4 ++
>  9 files changed, 392 insertions(+), 54 deletions(-)
>  create mode 100644 fs/fuse/backing.c
>

Hi Paul,

Are you still planning to continue work on this series? We have some
internal users at Meta who need this feature. I'm happy to pick this
up if you're no longer working on it, or collaborate if you'd prefer.

Thanks,
Joanne
> --
> 2.49.0.1112.g889b7c5bd8-goog
>
>