diff mbox series

fs/posix_acl: apply umask if superblock disables ACL support

Message ID 20230919081808.1096542-1-max.kellermann@ionos.com (mailing list archive)
State New, archived
Headers show
Series fs/posix_acl: apply umask if superblock disables ACL support | expand

Commit Message

Max Kellermann Sept. 19, 2023, 8:18 a.m. UTC 
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(-)

Comments

Christian Brauner Sept. 19, 2023, 1:10 p.m. UTC | #1 
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?
Max Kellermann Sept. 19, 2023, 1:15 p.m. UTC | #2 
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.
diff mbox series

Patch

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();