To the best of my understanding, there are two code paths which may yield FUSE_SYNCFS: one from user-space syscall syncfs(2) and the other from within the kernel itself. Unfortunately, there is no way to distinguish between the two at sb->s_op->sync_fs level, and the DoS argument refers to the second (kernel) case. If we could somehow propagate this info all the way down to the fuse layer then I see no reason for preventing (non-privileged) user-space programs from calling syncfs(2) over FUSE mounted file-systems. Please correct me if I am wrong with my analysis. - Shachar. On Fri, Aug 22, 2025 at 1:57 AM Bernd Schubert <bernd@xxxxxxxxxxx> wrote: > > > > On 8/22/25 00:28, Darrick J. Wong wrote: > > On Thu, Aug 21, 2025 at 03:18:11PM -0700, Joanne Koong wrote: > >> On Wed, Aug 20, 2025 at 5:52 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > >>> > >>> From: Darrick J. Wong <djwong@xxxxxxxxxx> > >>> > >>> Turn on syncfs for all fuse servers so that the ones in the know can > >>> flush cached intermediate data and logs to disk. > >>> > >>> Signed-off-by: "Darrick J. Wong" <djwong@xxxxxxxxxx> > >>> --- > >>> fs/fuse/inode.c | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> > >>> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c > >>> index 463879830ecf34..b05510799f93e1 100644 > >>> --- a/fs/fuse/inode.c > >>> +++ b/fs/fuse/inode.c > >>> @@ -1814,6 +1814,7 @@ int fuse_fill_super_common(struct super_block *sb, struct fuse_fs_context *ctx) > >>> if (!sb_set_blocksize(sb, ctx->blksize)) > >>> goto err; > >>> #endif > >>> + fc->sync_fs = 1; > >> > >> AFAICT, this enables syncfs only for fuseblk servers. Is this what you > >> intended? > > > > I meant to say for all fuseblk servers, but TBH I can't see why you > > wouldn't want to enable it for non-fuseblk servers too? > > > > (Maybe I was being overly cautious ;)) > > Just checked, the initial commit message has > > > <quote 2d82ab251ef0f6e7716279b04e9b5a01a86ca530> > Note that such an operation allows the file server to DoS sync(). Since a > typical FUSE file server is an untrusted piece of software running in > userspace, this is disabled by default. Only enable it with virtiofs for > now since virtiofsd is supposedly trusted by the guest kernel. > </quote> > > > With that we could at least enable for all privileged servers? And for > non-privileged this could be an async? > > > Thanks, > Bernd > > >
