On Sep 7, 2019, at 10:45 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski luto@amacapital.net wrote:
Linus, you rejected resolveat() because you wanted a *nice* API
No. I rejected resoveat() because it was a completely broken garbage API that couldn't do even basic stuff right (like O_CREAT).
We have a ton of flag space in the new openat2() model, we might as well leave the old flags alone that people are (a) used to and (b) we have code to support _anyway_.
Making up a new flag namespace is only going to cause us - and users - more work, and more confusion. For no actual advantage. It's not going to be "cleaner". It's just going to be worse.
If we keep all the flag bits in the same mask with the same values, then we’re stuck with O_RDONLY=0 and everything that implies. We’ll have UPGRADE_READ that works differently from the missing plain-old-READ bit, and we can’t express execute-only-no-read-or-write. This sucks.
Can we at least split the permission bits into their own mask and make bits 0 and 1 illegal in the main set of flags in openat2?
There’s another thread going on right now about adding a bit along the lines of “MAYEXEC”, and one of the conclusions was that it should wait for openat2 so that it can have same semantics. If we’re stuck with O_RDONLY and friends, then MAYEXEC is doomed to being at least a bit nonsensical.
As an analogy, AMD64 introduced bigger PTEs but kept the same nonsense encoding of read and write permission. And then we got NX, and now we’re getting little holes in the encoding stolen by CET to mean new silly things. I don’t know if you’ve been following the various rounds of patches, but it is truly horrible. The mapping from meaning to the actual bits is *shit*, and AMD64 should have made a clean break instead.
open()’s permission bits are basically the same situation. And the kernel *already* has a non-type-safe translation layer. Please, please let openat2() at least get rid of the turd in open()’s bits 0 and 1.