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

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: <CAHpGcMLbqOgHd=nbq6m_LinAk4S9zS80SfUUvU6Ah7d_p=OfFg@mail.gmail.com>
Date:	Wed, 27 May 2015 13:25:18 +0200
From:	Andreas Grünbacher <andreas.gruenbacher@...il.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
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

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:

                /*
                 * 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/