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: <m3y6ar9djc.fsf@linux.vnet.ibm.com>
Date:	Sat, 25 Sep 2010 00:25:51 +0530
From:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Jeff Layton <jlayton@...hat.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 11:50:49 -0400, Jeff Layton <jlayton@...hat.com> wrote:
> 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...
> 

To be POSIX compatible we need to ensure that additional file access
control mechanisms may only further restrict the access permissions defined
by the file permission bits. So with rich acl, similar to POSIX ACL,
we use file mask as an upper bound of the acess permission
allowed. Unlike POSIX ACL where the 'owner' and 'other' ACL entry access
mask is kept in sync with mode bits, rich acl include a file mask even
for 'owner' and 'everyone' entries. 

The patch that gives more details about the permission check algo can be
found at 

http://git.kernel.org/?p=linux/kernel/git/agruen/linux-2.6-richacl.git;a=commitdiff;h=442c675aeac85cfc893a2ec600f7fb3da3951177;hp=02456437cf280838a50ef00d7b4df2e7179fe6b2

-aneesh
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ