On Wed, Sep 03, 2025 at 06:01:00PM +0200, Miklos Szeredi wrote: > On Thu, 21 Aug 2025 at 02:51, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > If someone sets ACLs on a file that can be expressed fully as Unix DAC > > mode bits, most filesystems will then update the mode bits and drop the > > ACL xattr to reduce inefficiency in the file access paths. Let's do > > that too. Note that means that we can setacl and end up with no ACL > > xattrs, so we also need to tolerate ENODATA returns from > > fuse_removexattr. > > This goes against the model of leaving this sort of task to the > server. I understand your desire to do it in the kernel, since that > simplifies your server. But fuse is often used in passthrough mode, > where this will be done by the kernel, just one layer down the stack. > In that case splitting a setxattr into a removexattr + chmod makes > little sense. Ah, right. I temporarily forgot about network/cluster filesystems where the local kernel isn't necessarily in charge of the file metadata and permissions. > Maybe extend the meaning of fc->default_permissions to mean: userspace > doesn't want to deal with any mode related stuff. Thoughts? As suggested in the thread for the next patch, maybe I should just hide this new acl behavior behind (fc->iomap || sb->s_bdev != NULL)? --D > Thanks, > Miklos >
