[PATCH v3 0/2] fuse: allow FUSE_SYNCFS for privileged userspace servers

[Jimmy Zuber <jamz@amazon.com>]

FUSE_SYNCFS (propagating syncfs()/sync() to the server) is currently
enabled only for virtiofs and fuseblk, since an untrusted server can stall
sync(). Any FUSE filesystem may buffer data in the server that ought to
reach storage on sync(); the only thing that should gate it is whether the
/dev/fuse opener is sufficiently privileged to be trusted to block sync.

This series lets a plain /dev/fuse server opt in via a new FUSE_HAS_SYNCFS
INIT flag, honored only when the server opened /dev/fuse with CAP_SYS_ADMIN
privilege in the initial user namespace -- checked with file_ns_capable() at
mount time.

Extending syncfs propagation to another privileged mount class is not a new
direction: commit d3906d8f3cee ("fuse: enable FUSE_SYNCFS for all fuseblk
servers") already did the same for fuseblk. This series applies the same
reasoning to a plain /dev/fuse server, checking the opener's privilege
directly rather than inferring it from the mount type.

  Patch 1: the kernel change (UAPI flag + privilege gating).
  Patch 2: a selftest that speaks the raw FUSE protocol over /dev/fuse, so
           it can withhold the flag and directly observe whether the
           FUSE_SYNCFS opcode is forwarded.

A matching libfuse change (FUSE_CAP_SYNCFS negotiation) will be sent to the
libfuse project once the UAPI flag here is settled.

Changes since v2 [2]:
 - Rebased on current fuse.git for-next.  Since v2, bit 43 and minor
   version 46 were taken upstream (FUSE_HAS_IO_URING_BUFPOOL); FUSE_HAS_SYNCFS
   is now bit 44 and bumps the interface to minor version 47.
 - Selftest: dropped the v2 T4 case (an unprivileged user-namespace mount).
   With the v2 gating on the /dev/fuse opener's capability, T4 exercised the
   same "not capable -> withheld" branch as T3 while carrying the userns
   setup machinery; T3 (opener without CAP_SYS_ADMIN in the initial user
   namespace) is the surgical test of the gate and is retained.  No kernel
   behavior change.

Changes since v1 [1]:
 - Gate on the privilege of the opener (CAP_SYS_ADMIN in init_user_ns at
   /dev/fuse open time, via file_ns_capable()) rather than on the mount's
   user namespace.  Miklos pointed out that the v1 check
   (fc->user_ns == &init_user_ns) tested a property of the mount, not of
   the server that actually services -- and can stall -- the connection.
   Being in the initial user namespace is not itself a privilege
   (e.g. an ordinary sshfs mount qualifies).  Checking the device opener's
   capability closes that gap.
 - Selftest: add a case covering exactly that distinction -- a server
   in the initial user namespace that opened /dev/fuse without
   CAP_SYS_ADMIN -- which v1 would have wrongly allowed.

Testing: fs/fuse builds clean on the rebased tree.  Built and booted the
patched kernel; the selftest passes all three cases (T1 forwards
FUSE_SYNCFS; T2 and T3 withhold it), and a separate check on a
FUSE_WRITEBACK_CACHE mount confirmed the point of the change: after write()
the server had received 0 bytes (data dirty in the page cache), and after
syncfs() it received the full buffered payload followed by FUSE_SYNCFS.

[1] https://lore.kernel.org/20260616151909.916667-1-jamz@amazon.com
[2] https://lore.kernel.org/20260619170251.1154562-1-jamz@amazon.com

Jimmy Zuber (2):
  fuse: allow FUSE_SYNCFS for privileged userspace servers
  selftests/fuse: add test for FUSE_HAS_SYNCFS privilege gating

 fs/fuse/fuse_i.h                              |   9 +
 fs/fuse/inode.c                               |  28 ++
 include/uapi/linux/fuse.h                     |  12 +-
 .../selftests/filesystems/fuse/.gitignore     |   1 +
 .../selftests/filesystems/fuse/Makefile       |   2 +-
 .../selftests/filesystems/fuse/test_syncfs.c  | 309 ++++++++++++++++++
 6 files changed, 359 insertions(+), 2 deletions(-)
 create mode 100644 tools/testing/selftests/filesystems/fuse/test_syncfs.c


base-commit: d1dbc59200b54944f00251ca4dfbb2b318beca13
-- 
2.50.1