On Tue, Aug 26, 2025 at 12:31 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Fri, Aug 22, 2025 at 10:21:44AM -0700, Joanne Koong wrote: > > On Fri, Aug 22, 2025 at 4:32 AM Shachar Sharon <synarete@xxxxxxxxx> wrote: > > > > > > 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. > > > > I interpreted the DoS comment as referring to the scenario where a > > userspace program calls generic sync() and if an untrusted fuse > > server deliberately hangs on servicing that request then it'll hang > > sync forever. I think if this only affected the syncfs() syscall then > > it wouldn't be a problem since the caller is directly invoking it on a > > fuse fd, but if it affects generic sync() that seems like a big issue > > to me. Or at least that's my understanding of the code with > > ksys_sync() -> iterate_supers(sync_fs_one_sb, &wait). > > <shrug> I think you can already DoS sync() (and by extension any other > place in the kernel where we try to flush out all filesystems in one go) > by dropping a FUSE_SETATTR call on the floor, because that's how we > flush dirty inodes to disk? Or by doing the same for an FUSE_FSYNC > call? Isn't the sync() in fuse right now gated by fc->sync_fs (which is only set to true for virtiofsd)? I don't see where FUSE_SETATTR or FUSE_FSYNC get sent in the sync() path to untrusted servers. Thanks, Joanne > > --D >
