[GIT PULL 2/4] fuse4fs: run servers as a contained service

[GIT PULL 2/4] fuse4fs: run servers as a contained service

[Darrick J. Wong]

Hi Ted,

Please pull this branch with changes for ext4.

As usual, I did a test-merge with the main upstream branch as of a few
minutes ago, and didn't see any conflicts.  Please let me know if you
encounter any problems.

The following changes since commit 9199d64a91ea1cc8779cdc0289a79d50e6fe0ee2:

libext2fs: fix count recomputation in ext2fs_punch_ind (2026-09-11 23:34:15 -0700)

are available in the Git repository at:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/e2fsprogs.git tags/fuse4fs-service-container_2026-09-11

for you to fetch changes up to 8bf9ced74cb6f7cfc26dfbe0f8fff5ed13f51c90:

debian: update packaging for fuse4fs service (2026-09-11 23:35:02 -0700)

----------------------------------------------------------------
fuse4fs: run servers as a contained service [v6 2/4]

This series packages the newly created fuse4fs server into a systemd
socket service.  This service can be used by the "mount.service" helper
in libfuse to implement untrusted unprivileged mounts.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>

----------------------------------------------------------------
Darrick J. Wong (10):
libext2fs: make it possible to extract the fd from an IO manager
libext2fs: fix checking for valid fds in mmp.c
unix_io: allow passing /dev/fd/XXX paths to the unixfd IO manager
libext2fs: fix MMP code to work with unixfd IO manager
libext2fs: bump libfuse API version to 3.19
fuse4fs: hoist some code out of fuse4fs_main
fuse4fs: enable safe service mode
fuse4fs: set proc title when in fuse service mode
fuse4fs: make MMP work correctly in safe service mode
debian: update packaging for fuse4fs service

lib/ext2fs/ext2_io.h         |   4 +-
lib/ext2fs/ext2fs.h          |   1 +
lib/ext2fs/ext2fsP.h         |   4 +
MCONFIG.in                   |   2 +
configure                    | 303 ++++++++++++++++++++++++++-
configure.ac                 | 131 +++++++++++-
debian/e2fsprogs.install     |   7 +-
debian/fuse4fs.install       |   3 +
debian/libext2fs2t64.symbols |   1 +
debian/rules                 |   3 +
fuse4fs/Makefile.in          |  42 +++-
fuse4fs/fuse4fs.c            | 479 ++++++++++++++++++++++++++++++++++++-------
fuse4fs/fuse4fs.socket.in    |  17 ++
fuse4fs/fuse4fs@.service.in  | 102 +++++++++
lib/config.h.in              |  12 ++
lib/ext2fs/io_manager.c      |   8 +
lib/ext2fs/mmp.c             | 101 ++++++++-
lib/ext2fs/openfs.c          |   1 +
lib/ext2fs/unix_io.c         |  50 ++++-
util/subst.conf.in           |   3 +
20 files changed, 1177 insertions(+), 97 deletions(-)
mode change 100644 => 100755 debian/fuse4fs.install
create mode 100644 fuse4fs/fuse4fs.socket.in
create mode 100644 fuse4fs/fuse4fs@.service.in

Re: [GIT PULL 2/4] fuse4fs: run servers as a contained service

[Theodore Tso]

On Fri, Sep 11, 2026 at 11:41:59PM -0500, Darrick J. Wong wrote:
> libext2fs: fix MMP code to work with unixfd IO manager

So a quick comment about this:

       * It's also broken if the unixfd IO manager was passed a string with a
       * file descriptor number instead of a /dev/fd/XX path, but the
       * internet thinks there are no users of the manager outside of Google.

Specifically, it's not Google, it's "Android", and it's used for a
similar reason as unprivileged containerized use case --- namely
security.  In the case of Android, a volume server daemon passes the
file descriptor over a unix domain socket so that the fsck can be run
on the file system without giving it wider access to the system.  The
difference is that Android didn't care about MMP, so they never tested
or cared about that particular corner case.

Honestly, MMP only really makes sense when you have specialized
hardware where the storage device can be simultaneously connected to
two host servers, and you want to do block device level failover
between devices.  This doesn't really make sense for Android or for
the containerized fuse service, so _not_ supporting it for FUSE (or
Android) is a perfectly valid choice.

Even in the software defined block device world for Cloud VM's, you
generally don't need it because this can be handled at the control
plane level.  For example, Google Cloud's Persistent Disk has an I/O
fencing feature where if one of the VM loses network connectivity, you
can do a forced failover where the backup VM can "take over" the cloud
disk, and the previous VM that had exclusive writer access will have
its access cut off before the secondary VM gains exclusive write
access to the disk.  If you have this, you don't need MMP.

Cheers,

						- Ted
						

Re: [GIT PULL 2/4] fuse4fs: run servers as a contained service

[Darrick J. Wong]

On Tue, Sep 22, 2026 at 08:46:50PM -0400, Theodore Tso wrote:
> On Fri, Sep 11, 2026 at 11:41:59PM -0500, Darrick J. Wong wrote:
> > libext2fs: fix MMP code to work with unixfd IO manager
> 
> So a quick comment about this:
> 
>        * It's also broken if the unixfd IO manager was passed a string with a
>        * file descriptor number instead of a /dev/fd/XX path, but the
>        * internet thinks there are no users of the manager outside of Google.
> 
> Specifically, it's not Google, it's "Android", and it's used for a
> similar reason as unprivileged containerized use case --- namely
> security.  In the case of Android, a volume server daemon passes the
> file descriptor over a unix domain socket so that the fsck can be run
> on the file system without giving it wider access to the system.  The
> difference is that Android didn't care about MMP, so they never tested
> or cared about that particular corner case.
> 
> Honestly, MMP only really makes sense when you have specialized
> hardware where the storage device can be simultaneously connected to
> two host servers, and you want to do block device level failover
> between devices.  This doesn't really make sense for Android or for
> the containerized fuse service, so _not_ supporting it for FUSE (or
> Android) is a perfectly valid choice.
> 
> Even in the software defined block device world for Cloud VM's, you
> generally don't need it because this can be handled at the control
> plane level.  For example, Google Cloud's Persistent Disk has an I/O
> fencing feature where if one of the VM loses network connectivity, you
> can do a forced failover where the backup VM can "take over" the cloud
> disk, and the previous VM that had exclusive writer access will have
> its access cut off before the secondary VM gains exclusive write
> access to the disk.  If you have this, you don't need MMP.

<shrug> So what should we do?  I'd be fine with dropping the patch and
simply not supporting MMP in containerized fuse*fs.  It's a rather niche
feature anyway.

--D

> Cheers,
> 
> 						- Ted
> 						
>