Message-ID: <20250617221456.888231-1-paullawrence@google.com>
Date: Tue, 17 Jun 2025 15:14:52 -0700
From: Paul Lawrence <paullawrence@...gle.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	Paul Lawrence <paullawrence@...gle.com>
Subject: [PATCH v1 0/2] RFC: Extend fuse-passthrough to directories

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

-- 
2.49.0.1112.g889b7c5bd8-goog

Powered by blists - more mailing lists