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