From: Jimmy Zuber <jamz@amazon.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: <fuse-devel@lists.linux.dev>, <linux-fsdevel@vger.kernel.org>,
<linux-api@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Shuah Khan <shuah@kernel.org>, <linux-kselftest@vger.kernel.org>
Subject: [PATCH 0/2] fuse: allow FUSE_SYNCFS for privileged userspace servers
Date: Tue, 16 Jun 2026 15:19:07 +0000 [thread overview]
Message-ID: <20260616151909.916667-1-jamz@amazon.com> (raw)
FUSE_SYNCFS (propagating syncfs()/sync() to the server) is currently
enabled only for virtiofs and fuseblk, since an untrusted server can stall
sync(). But any FUSE filesystem may buffer data in the server that should
reach storage on sync(); the only thing that should gate it is whether the
mount was set up with host privilege. This series lets a plain /dev/fuse
server opt in via a new FUSE_HAS_SYNCFS INIT flag, honored only for mounts
owned by the initial user namespace. Patch 1 has the full rationale and
the security argument.
Patch 1: the kernel change (UAPI flag + gating in process_init_reply()).
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 -- covering the privileged,
opt-out, and unprivileged-userns cases.
A matching libfuse change (FUSE_CAP_SYNCFS negotiation) will be sent to the
libfuse project once the UAPI flag here is settled.
Testing: built and booted under QEMU (x86_64). The selftest passes all
three cases. A separate end-to-end 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 -- i.e. syncfs() flushes
cached data to the server on a privileged mount.
Jimmy Zuber (2):
fuse: allow FUSE_SYNCFS for privileged userspace servers
selftests/fuse: add test for FUSE_HAS_SYNCFS privilege gating
fs/fuse/inode.c | 16 +
include/uapi/linux/fuse.h | 11 +-
.../selftests/filesystems/fuse/.gitignore | 1 +
.../selftests/filesystems/fuse/Makefile | 2 +-
.../selftests/filesystems/fuse/test_syncfs.c | 318 ++++++++++++++++++
5 files changed, 346 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/filesystems/fuse/test_syncfs.c
base-commit: 7d87a5a284bb34edb3f4e7e312ef403b3385a7b7
--
2.50.1
next reply other threads:[~2026-06-16 15:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 15:19 Jimmy Zuber [this message]
2026-06-16 15:19 ` [PATCH 1/2] fuse: allow FUSE_SYNCFS for privileged userspace servers Jimmy Zuber
2026-06-16 15:19 ` [PATCH 2/2] selftests/fuse: add test for FUSE_HAS_SYNCFS privilege gating Jimmy Zuber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260616151909.916667-1-jamz@amazon.com \
--to=jamz@amazon.com \
--cc=fuse-devel@lists.linux.dev \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.