Re: [RFC v3 14/45] richacl: Permission check algorithm

[Andreas GrÃnbacher]

2015-05-22 23:08 GMT+02:00 J. Bruce Fields <bfields@xxxxxxxxxxxx>:
> 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:

                /*
                 * Apply the group file mask to entries other than OWNER@ and
                 * EVERYONE@. This is not required for correct access checking
                 * but ensures that we grant the same permissions as the acl
                 * computed by richacl_apply_masks() would grant.
                 */

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.

Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/