linux-kernel - Re: [PATCH] fs: fix regression querying for ACL on fs's that don't support them

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230910-gingen-maulkorb-918c8c2ce6bf@brauner>
Date:   Sun, 10 Sep 2023 12:14:30 +0200
From:   Christian Brauner <brauner@...nel.org>
To:     Jeff Layton <jlayton@...nel.org>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Anna Schumaker <anna@...nel.org>,
        Ondrej Valousek <ondrej.valousek.xm@...esas.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-nfs@...r.kernel.org
Subject: Re: [PATCH] fs: fix regression querying for ACL on fs's that don't
 support them

On Fri, Sep 08, 2023 at 05:05:27PM -0400, Jeff Layton wrote:
> In the not too distant past, the VFS ACL infrastructure would return
> -EOPNOTSUPP on filesystems (like NFS) that set SB_POSIXACL but that
> don't supply a get_acl or get_inode_acl method. On more recent kernels
> this returns -ENODATA, which breaks one method of detecting when ACLs
> are supported.
> 
> Fix __get_acl to also check whether the inode has a "get_(inode_)?acl"
> method and to just return -EOPNOTSUPP if not.
> 
> Reported-by: Ondrej Valousek <ondrej.valousek.xm@...esas.com>
> Signed-off-by: Jeff Layton <jlayton@...nel.org>
> ---
> This patch is another approach to fixing this issue. I don't care too
> much either way which approach we take, but this may fix the problem
> for other filesystems too. Should we take a belt and suspenders
> approach here and fix it in both places?
> ---
>  fs/posix_acl.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/posix_acl.c b/fs/posix_acl.c
> index a05fe94970ce..4c7c62040c43 100644
> --- a/fs/posix_acl.c
> +++ b/fs/posix_acl.c
> @@ -130,8 +130,12 @@ static struct posix_acl *__get_acl(struct mnt_idmap *idmap,
>  	if (!is_uncached_acl(acl))
>  		return acl;
>  
> -	if (!IS_POSIXACL(inode))
> -		return NULL;
> +	/*
> +	 * NB: checking this after checking for a cached ACL allows tmpfs
> +	 * (which doesn't specify a get_acl operation) to work properly.
> +	 */
> +	if (!IS_POSIXACL(inode) || (!inode->i_op->get_acl && !inode->i_op->get_inode_acl))
> +		return ERR_PTR(-EOPNOTSUPP);

Hmmm, I think that'll cause issues for permission checking during
lookup:

generic_permission()
-> acl_permission_check()
   -> check_acl()
      -> get_inode_acl()
         -> __get_acl()
            // return ERR_PTR(-EOPNOTSUPP) instead of NULL

Before this change this would've returned NULL and thus check_acl()
would've returned EAGAIN which would've informed acl_permission_check()
to continue with non-ACL based permission checking.

Now you're going to error out with EOPNOTSUPP and cause permission
checking to fallback to CAP_DAC_READ_SEARCH/CAP_DAC_OVERRIDE.

So if you want this change you'll either need to change check_acl() as well.
Unless I'm misreading.