On Wed 11-10-23 13:00:42, Theodore Ts'o wrote: > On Wed, Oct 11, 2023 at 05:27:37PM +0200, Christian Brauner wrote: > > Aside from that, the problem had been that filesystems like nfs v4 > > intentionally raised SB_POSIXACL to prevent umask stripping in the VFS. > > IOW, for them SB_POSIXACL was equivalent to "don't apply any umask". > > > > And afaict nfs v4 has it's own thing going on how and where umasks are > > applied. However, since we now have the following commit in vfs.misc: > > > > fs: add a new SB_I_NOUMASK flag > > To summarize, just to make sure I understand where we're going. Since > normally (excepting unusual cases like NFS), it's fine to strip the > umask bits twice (once in the VFS, and once in the file system, for > those file systems that are doing it), once we have SB_I_NOUMASK and > NFS starts using it, then the VFS can just unconditionally strip the > umask bits, and then we can gradually clean up the file system umask > handling (which would then be harmlessly duplicative). > > Did I get this right? I don't think this is accurate. posix_acl_create() needs unmasked 'mode' because instead of using current_umask() for masking it wants to use whatever is stored in the ACLs as an umask. So I still think we need to keep umask handling in both posix_acl_create() and vfs_prepare_mode(). But filesystem's only obligation would be to call posix_acl_create() if the inode is IS_POSIXACL. No more caring about when to apply umask and when not based on config or mount options. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
