On Wed, Sep 03, 2025 at 06:15:30PM +0200, Miklos Szeredi wrote: > On Thu, 21 Aug 2025 at 02:52, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > Propagate the default and file access ACLs to new children when creating > > them, just like the other kernel filesystems. > > Another problem of this and the previous patch is being racy. Not > "real" filesystems like fuse2fs, but this is going to trip network fs > up badly, where such races would be really difficult to test. Ahh, right -- I neglected that the fuse interface is more or less what you'd need for a client node of a network/cluster filesystem. > We could add a new feature flag, but we seem to have proliferation of > this sort. We have default_permissions, then handle_killpriv, then > handle_killpriv_v2. Seems like we need a flag to tell the kernel to > treat this as a local fs, where it can do all the local fs'y things > without fear of breaking remote fs. > > Does that make sense? Yeah. How about I hide the functionality of this ACL patch and the previous one behind (fc->iomap || sb->s_bdev != NULL)? The iomap functionality that I'm working on is only useful for filesystems that want to behave like a local fs, including all the "I went out to lunch DoS" warts. AFAICT the other fuse developers seem to accept that fuseblk servers can do that too. Does that sound ok? If anyone ever wanted to use fuse+iomap for a cluster fs, I guess I'd have to go back to issuing FUSE_READ/WRITE requests to userspace for permission checking and resource acquisition. But so far no cluster filesystems use fs/iomap/ so it's just unsupported. (And to make this explicit to anyone watching on the list -- all of my work is completely separate from Joanne's efforts to adapt fuse to use iomap for tracking pagecache dirty state.) --D > Thanks, > Miklos
