Re: posix_acl_permission() and MAY_* flags

From: Andreas Dilger <adilger@dilger.ca>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com>,
	"Andreas Gruenbacher" <agruenba@redhat.com>,
	"Linux FS-devel Mailing List" <linux-fsdevel@vger.kernel.org>
Subject: Re: posix_acl_permission() and MAY_* flags
Date: Fri, 12 Oct 2018 22:08:57 -0600	[thread overview]
Message-ID: <0C0A87C5-C1B8-42F8-A9C4-C355DDBC1B8F@dilger.ca> (raw)
In-Reply-To: <20181013035611.GL32577@ZenIV.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

On Oct 12, 2018, at 9:56 PM, Al Viro <viro@ZenIV.linux.org.uk> wrote:
> 
> On Fri, Oct 12, 2018 at 11:09:38AM +0200, Andreas Grünbacher wrote:
> 
>> The ACL_{READ,WRITE,EXECUTE} and MAY_{READ,WRITE,EXEC} values must
>> definitely have the same values. This wouldn't be true for higher
>> bits, but POSIX ACLs don't support anything beyond rwx.
> 
> Yes.  What's more, nobody is going to change the values for any of
> those - consider them tied to pretty much universal encoding going
> through all Unix filesystem layouts and all Unix ABIs.
> 
> Not all uses of symbolic constants mean that the values can be
> redefined.  In particular, MAY_READ == R_OK, etc. - the names
> are not directly exposed to userland, but attempt to change the
> values will immediately break access(2) or demand remapping in
> it.  They are also tied to on-disk layouts.
> 
> If you want BUILD_BUG_ON() on those, we could add such, but I
> really don't see the point - anyone changing any of those will
> get instant breakage as soon as they try to boot.  Or the patch
> will have a very heavy footprint and raise obvious red flags on
> review (along the lines of "WTF do you insert that crap on a lot
> of hot paths?  You are changing what, again?  What for?")

It's not that I'm _so_ worried about the values changing, just
that I was following the ACL code paths around, and the caller
is passing in MAY_* flags on the one side, but then comparing
them to values set from S_I*OTH flags on disk and it made me
wonder if something was broken, or if it might break in the future.

I would definitely agree that S_I* flags are set in stone, but
I've never really thought of MAY_* flags as being directly tied
to on-disk values because there are so many more than just
MAY_{READ,WRITE,EXECUTE} - MAY_APPEND, MAY_OPEN, etc.  I'd always
thought of them like the EXT4_IMMUTABLE_FL on-disk flags vs.
the S_IMMUTABLE inode flags in memory.

Cheers, Andreas

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]