linux-kernel - Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

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]

Date:	Wed, 23 Sep 2015 22:29:40 +0200
From:	Andreas Gruenbacher <agruenba@...hat.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-nfs@...r.kernel.org, linux-api@...r.kernel.org,
	linux-cifs@...r.kernel.org, linux-security-module@...r.kernel.org,
	Andreas Gruenbacher <agruen@...nel.org>
Subject: Re: [RFC v7 26/41] richacl: Apply the file masks to a richacl

2015-09-23 21:18 GMT+02:00 J. Bruce Fields <bfields@...ldses.org>:
> On Tue, Sep 22, 2015 at 03:11:08PM -0400, bfields wrote:
>> user aces like owner aces what you intended to do,
>> and if so, why?
>
> That does look wrong to me; in an example like:
>
>         file owner bfields
>         mask 0700, not WRITE_THROUGH
>         bfields:rwx::allow
>
> The permission algorithm grants nothing to anyone, but it looks to me
> like richacl_apply_masks just leaves this as
>
>         bfields:rwx::allow
>
> but it would give the right result (an empty/deny-all ACL) if it weren't
> for this odd case here.

In POSIX ACLs, only the entry that best matches the process determines
the access permissions. For the file owner, this would always be the
"user::" entry, and such an entry always exists.

In richacls, permissions from multiple entries do accumulate; the
permission check algorithm does not pick a "best match". When bfields
owns a file and a "bfields:rwx::allow" entry exists, denying rwx
access to bfields would be very surprising. It makes more sense to put
user entries that match the current owner into the owner class, and
apply the owner mask instead of the group mask. This was working in an
earlier version but apparently broke at some point.

So the result that richacl_apply_masks computes here is correct, and
the permission check algorithm needs a little fix.

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/