linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>
Subject: Re: posix_acl_permission() and MAY_* flags
Date: Sat, 13 Oct 2018 04:56:11 +0100	[thread overview]
Message-ID: <20181013035611.GL32577@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAHpGcMKV8MnKNovt4H7ZfjJtQ5AAaD+hC5L65mAWtV5MeKu_kA@mail.gmail.com>

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?")

  reply	other threads:[~2018-10-13 11:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1254FD78-8392-4B97-A191-EDA01B719635@whamcloud.com>
2018-10-12  0:43 ` Fwd: posix_acl_permission() and MAY_* flags Andreas Dilger
2018-10-12  9:09   ` Andreas Grünbacher
2018-10-13  3:56     ` Al Viro [this message]
2018-10-13  4:08       ` Andreas Dilger
2018-10-13  4:37         ` Al Viro
2018-10-13  3:40   ` Fwd: " Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181013035611.GL32577@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=adilger@dilger.ca \
    --cc=agruenba@redhat.com \
    --cc=andreas.gruenbacher@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).