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 1/2] fuse: allow FUSE_SYNCFS for privileged userspace servers
Date: Tue, 16 Jun 2026 15:19:08 +0000 [thread overview]
Message-ID: <20260616151909.916667-2-jamz@amazon.com> (raw)
In-Reply-To: <20260616151909.916667-1-jamz@amazon.com>
Propagating syncfs()/sync() to a FUSE server via FUSE_SYNCFS lets the
server flush its own cached or intermediate state when userspace asks the
filesystem to sync. This is currently enabled only for virtiofs and
fuseblk, because an untrusted server can use it to stall sync()
indefinitely (see commit 2d82ab251ef0 ("virtiofs: propagate sync() to file
server"), and commit d3906d8f3cee ("fuse: enable FUSE_SYNCFS for all
fuseblk servers")). Both of those mount types require host privilege to
set up, so the server is trusted not to abuse it.
There is nothing virtiofs- or block-specific about wanting to handle
syncfs(), though. A plain /dev/fuse server is just as entitled to
participate in the sync() path -- so that data it has buffered reaches
stable storage when the user asks for it -- provided it is equally
trusted. The relevant trust boundary is whether the mount was set up with
host privilege.
Add an opt-in INIT flag, FUSE_HAS_SYNCFS, and enable propagation only when
both:
- the server sets FUSE_HAS_SYNCFS in its INIT reply, and
- the mount is owned by the initial user namespace
(fc->user_ns == &init_user_ns).
The user namespace check is the key restriction. A regular fuse mount is
mountable from a non-initial user namespace (FS_USERNS_MOUNT), where the
server is untrusted; the VFS already marks such mounts with
SB_I_UNTRUSTED_MOUNTER. Restricting FUSE_SYNCFS to init_user_ns mounts
preserves the original DoS protection for unprivileged servers in full,
while mirroring how virtiofs and fuseblk earn syncfs by construction
(neither is mountable from a non-initial user namespace).
The flag is only advertised to servers whose mount is owned by the initial
user namespace, so an unprivileged server is never invited to opt in (and
is ignored by fuse_syncfs_enable() if it sets the flag anyway).
Signed-off-by: Jimmy Zuber <jamz@amazon.com>
Assisted-by: Claude:claude-opus-4-8 [Claude-Code]
---
fs/fuse/inode.c | 16 ++++++++++++++++
include/uapi/linux/fuse.h | 11 ++++++++++-
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index d975073c6029..d0005a373729 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -1266,6 +1266,16 @@ struct fuse_init_args {
struct fuse_mount *fm;
};
+/*
+ * A server can stall syncfs()/sync(), so only honor FUSE_HAS_SYNCFS for
+ * mounts owned by the initial user namespace, i.e. set up with host
+ * privilege (like virtiofs and fuseblk).
+ */
+static bool fuse_syncfs_enable(struct fuse_conn *fc, u64 flags)
+{
+ return (flags & FUSE_HAS_SYNCFS) && fc->user_ns == &init_user_ns;
+}
+
static void process_init_reply(struct fuse_args *args, int error)
{
struct fuse_init_args *ia = container_of(args, typeof(*ia), args);
@@ -1406,6 +1416,9 @@ static void process_init_reply(struct fuse_args *args, int error)
if (flags & FUSE_REQUEST_TIMEOUT)
timeout = arg->request_timeout;
+
+ if (fuse_syncfs_enable(fc, flags))
+ fc->sync_fs = 1;
} else {
ra_pages = fc->max_read / PAGE_SIZE;
fc->no_lock = 1;
@@ -1473,6 +1486,9 @@ static struct fuse_init_args *fuse_new_init(struct fuse_mount *fm)
flags |= FUSE_SUBMOUNTS;
if (IS_ENABLED(CONFIG_FUSE_PASSTHROUGH))
flags |= FUSE_PASSTHROUGH;
+ /* Only offered to host-privileged mounts; see fuse_syncfs_enable(). */
+ if (fm->fc->user_ns == &init_user_ns)
+ flags |= FUSE_HAS_SYNCFS;
/*
* This is just an information flag for fuse server. No need to check
diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
index c13e1f9a2f12..de1002063ca2 100644
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -240,6 +240,9 @@
* - add FUSE_COPY_FILE_RANGE_64
* - add struct fuse_copy_file_range_out
* - add FUSE_NOTIFY_PRUNE
+ *
+ * 7.46
+ * - add FUSE_HAS_SYNCFS opt-in flag for privileged userspace servers
*/
#ifndef _LINUX_FUSE_H
@@ -275,7 +278,7 @@
#define FUSE_KERNEL_VERSION 7
/** Minor version number of this interface */
-#define FUSE_KERNEL_MINOR_VERSION 45
+#define FUSE_KERNEL_MINOR_VERSION 46
/** The node ID of the root inode */
#define FUSE_ROOT_ID 1
@@ -448,6 +451,11 @@ struct fuse_file_lock {
* FUSE_OVER_IO_URING: Indicate that client supports io-uring
* FUSE_REQUEST_TIMEOUT: kernel supports timing out requests.
* init_out.request_timeout contains the timeout (in secs)
+ * FUSE_HAS_SYNCFS: server requests that syncfs()/sync() be propagated as
+ * FUSE_SYNCFS requests. Only honored by the kernel for mounts
+ * owned by the initial user namespace (i.e. set up with real
+ * host privilege), since an untrusted server can use this to
+ * stall sync(). Unprivileged (user namespace) mounts ignore it.
*/
#define FUSE_ASYNC_READ (1 << 0)
#define FUSE_POSIX_LOCKS (1 << 1)
@@ -495,6 +503,7 @@ struct fuse_file_lock {
#define FUSE_ALLOW_IDMAP (1ULL << 40)
#define FUSE_OVER_IO_URING (1ULL << 41)
#define FUSE_REQUEST_TIMEOUT (1ULL << 42)
+#define FUSE_HAS_SYNCFS (1ULL << 43)
/**
* CUSE INIT request/reply flags
--
2.50.1
next prev parent reply other threads:[~2026-06-16 15:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 15:19 [PATCH 0/2] fuse: allow FUSE_SYNCFS for privileged userspace servers Jimmy Zuber
2026-06-16 15:19 ` Jimmy Zuber [this message]
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-2-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.