Message-ID: <20150527150522.GA21309@fieldses.org>
Date:	Wed, 27 May 2015 11:05:22 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Andreas Grünbacher 
	<andreas.gruenbacher@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org
Subject: Re: [RFC v3 14/45] richacl: Permission check algorithm

On Wed, May 27, 2015 at 01:25:18PM +0200, Andreas Grünbacher wrote:
> 2015-05-22 23:08 GMT+02:00 J. Bruce Fields <bfields@...ldses.org>:
> > On Fri, Apr 24, 2015 at 01:04:11PM +0200, Andreas Gruenbacher wrote:
> >> A richacl grants a requested access if the NFSv4 acl in the richacl
> >> grants the requested permissions (according to the NFSv4 permission
> >> check algorithm) and the file mask that applies to the process
> >> includes the requested permissions.
> >
> > Is that right?  Based on that I'd have thought that an acl like
> >
> >         owner  :r::mask
> >         group  :-::mask
> >         other  :-::mask
> >         bfields:r::allow
> >
> > would permit read to bfields in the case bfields is the file owner,
> > because both the mask entries and the NFSv4 ACL would permit access.
> >
> > But I think it doesn't (because the "bfields" entry is subject to the
> > group mask).
> 
> The problem at cause here that if we treat the acl and masks completely
> separately, we can end up with acl/mask combinations that don't have a
> representation as "normal" acls. For example, this:
> 
>    owner:r::mask
>    group:-::mask
>    other:-::mask
>   group@:r::allow
> 
> would grant the owner read access when in the owning group, but
> wouldn't grant the owning group access. This is handled by applying
> the group mask to all group-class entries; see this comment in the
> code:

OK, good, that makes sense, so I think all that's needed is some updates
to documentation; for example:

>                 /*
>                  * Apply the group file mask to entries other than OWNER@ and
>                  * EVERYONE@. This is not required for correct access checking

This is a strange way to put it; it makes it sound like the logic here
might not affect the access check result at all.

And this routine is basically the definition of the access check
algorithm, so the logic here is required.

>                  * but ensures that we grant the same permissions as the acl
>                  * computed by richacl_apply_masks() would grant.

I mean, I do understand what you're saying here, but it's a slightly
backwards way to put it....

>                  */
> 
> There is no necessity to also apply this rule to user entries matching the
> current owner though; we can change that here and in richacl_apply_masks().
> 
> > But if I'm right, I'm not sure how to describe the algorithm concisely.
> 
> Right, it's all a bit messy.

We need to put some thought into how this will be explained in man pages
and such, if you don't have that already.  It's inherently a complicated
ACL model, and hopefully this sort of corner case can be ignored most of
the time, but we need a good complete explanation somewhere that a
stressed sysadmin can follow if they need it....

I wish we could do something a little dumber and simpler, e.g., like

	http://docs.openafs.org/UserGuide/HDRWQ59.html

but maybe it's not practical.

--b.
--
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