On 2019-09-09, Mickaël Salaün [off-list ref] wrote:

On 06/09/2019 21:03, James Morris wrote:

quoted

On Fri, 6 Sep 2019, Jeff Layton wrote:

quoted

The fact that open and openat didn't vet unknown flags is really a bug.

Too late to fix it now, of course, and as Aleksa points out, we've
worked around that in the past. Now though, we have a new openat2
syscall on the horizon. There's little need to continue these sorts of
hacks.

New open flags really have no place in the old syscalls, IMO.

Agree here. It's unfortunate but a reality and Linus will reject any such
changes which break existing userspace.

Do you mean that adding new flags to open(2) is not possible?

It is possible, as long as there is no case where a program that works
today (and passes garbage to the unused bits in flags) works with the
change.

O_TMPFILE was okay because it's actually two flags (one is O_DIRECTORY)
and no working program does file IO to a directory (there are also some
other tricky things done there, I'll admit I don't fully understand it).

O_EMPTYPATH works because it's a no-op with non-empty path strings, and
empty path strings have always given an error (so no working program
does it today).

However, O_MAYEXEC will result in programs that pass garbage bits to
potentially get -EACCES that worked previously.

As I said, O_MAYEXEC should be ignored if it is not supported by the
kernel, which perfectly fit with the current open(2) flags behavior, and
should also behave the same with openat2(2).

NACK on having that behaviour with openat2(2). -EINVAL on unknown flags
is how all other syscalls work (any new syscall proposed today that
didn't do that would be rightly rejected), and is a quirk of open(2)
which unfortunately cannot be fixed. The fact that *every new O_ flag
needs to work around this problem* should be an indication that this
interface mis-design should not be allowed to infect any more syscalls.

Note that this point is regardless of the fact that O_MAYEXEC is a
*security* flag -- if userspace wants to have a secure fallback on
old kernels (which is "the right thing" to do) they would have to do
more work than necessary. And programs that don't care don't have to do
anything special.

However with -EINVAL, the programs doing "the right thing" get an easy
-EINVAL check. And programs that don't care can just un-set O_MAYEXEC
and retry. You should be forced to deal with the case where a flag is
not supported -- and this is doubly true of security flags!

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>