The function posix_acl_create() applies the umask only if the inode has no ACL (= NULL) or if ACLs are not supported by the filesystem driver (= -EOPNOTSUPP).
However, this happens only after after the IS_POSIXACL() check succeeded. If the superblock doesn't enable ACL support, umask will never be applied. A filesystem which has no ACL support will of course not enable SB_POSIXACL, rendering the umask-applying code path unreachable.
This fixes a bug which causes the umask to be ignored with O_TMPFILE on tmpfs:
https://github.com/MusicPlayerDaemon/MPD/issues/558 https://bugs.gentoo.org/show_bug.cgi?id=686142#c3 https://bugzilla.kernel.org/show_bug.cgi?id=203625
Reviewed-by: J. Bruce Fields bfields@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Max Kellermann max.kellermann@ionos.com --- fs/posix_acl.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/posix_acl.c b/fs/posix_acl.c index a05fe94970ce..79831269dd2f 100644 --- a/fs/posix_acl.c +++ b/fs/posix_acl.c @@ -642,9 +642,14 @@ posix_acl_create(struct inode *dir, umode_t *mode, *acl = NULL; *default_acl = NULL;
- if (S_ISLNK(*mode) || !IS_POSIXACL(dir)) + if (S_ISLNK(*mode)) return 0;
+ if (!IS_POSIXACL(dir)) { + *mode &= ~current_umask(); + return 0; + } + p = get_inode_acl(dir, ACL_TYPE_DEFAULT); if (!p || p == ERR_PTR(-EOPNOTSUPP)) { *mode &= ~current_umask();
On Tue, Sep 19, 2023 at 10:18:07AM +0200, Max Kellermann wrote:
The function posix_acl_create() applies the umask only if the inode has no ACL (= NULL) or if ACLs are not supported by the filesystem driver (= -EOPNOTSUPP).
However, this happens only after after the IS_POSIXACL() check succeeded. If the superblock doesn't enable ACL support, umask will never be applied. A filesystem which has no ACL support will of course not enable SB_POSIXACL, rendering the umask-applying code path unreachable.
The fix is in the wrong place if !IS_POSIXACL() umask stripping happens in the VFS. So if at all we need to fix stripping umask for O_TMPFILE in the vfs.
Have you verified that commit ac6800e279a2 ("fs: Add missing umask strip in vfs_tmpfile") doesn't already fix this?
On Tue, Sep 19, 2023 at 3:10 PM Christian Brauner brauner@kernel.org wrote:
Have you verified that commit ac6800e279a2 ("fs: Add missing umask strip in vfs_tmpfile") doesn't already fix this?
No, I havn't - I submitted this patch already several years ago, but it was never merged, and since then, I've been carrying this patch around in all kernels I ever used. While doing some other kernel work this week, I decided to resubmit it, because I thought it's a security vulnerability to ignore the umask. But thanks, it's a good hint, I'll check that 2022 commit.
linux-stable-mirror@lists.linaro.org
-
Christian Brauner -
Max Kellermann