linux-kernel - Re: [PATCH -V4 07/11] vfs: Make acl_permission

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: <20100924115049.47b1217b@tlielax.poochiereds.net>
Date:	Fri, 24 Sep 2010 11:50:49 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	sfrench@...ibm.com, ffilz@...ibm.com, agruen@...e.de,
	adilger@....com, sandeen@...hat.com, tytso@....edu,
	bfields@...i.umich.edu, linux-fsdevel@...r.kernel.org,
	nfsv4@...ux-nfs.org, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -V4 07/11] vfs: Make acl_permission_check() work for
 richacls

On Fri, 24 Sep 2010 18:18:10 +0530
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com> wrote:

> From: Andreas Gruenbacher <agruen@...e.de>
> 
> Signed-off-by: Andreas Gruenbacher <agruen@...e.de>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>
> ---
>  fs/namei.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 855b360..b0b8a71 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -174,6 +174,12 @@ static int acl_permission_check(struct inode *inode, int mask,
>  {
>  	umode_t			mode = inode->i_mode;
>  
> +	if (IS_RICHACL(inode)) {
> +		int error = check_acl(inode, mask);
> +		if (error != -EAGAIN)
> +			return error;
> +	}
> +
>  	if (current_fsuid() == inode->i_uid)
>  		mode >>= 6;
>  	else {

This may just be my own ignorance of ACL semantics and unfamiliarity
with the ACL code in general. It seems a bit unusual though...

Just to be clear...this patch implies that with richacls you can deny
or grant access to the owner of the file even if the mode bits say
otherwise. With POSIX acls, this seems to be the other way around.

Hmm....guess I should read the spec...

-- 
Jeff Layton <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/