fexecve, round 3

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Let's try to move forward, and I will start will a sum up of what I
understand from the standard. It would be nice if we could at least
reach consensus on standard interpretation.

We have two operations: 
- Open stage: openat() of a file
- Exec stage: fexecve() using the file descriptor obtained on open
stage.

There are two alternatives ways of doing the two stages:
Way 1:
- open stage: openat() using O_RDONLY, O_WRONLY, or O_RDWR
- exec stage: fexecve() will check --x mode on file descriptor

Way 2:
- open stage: openat() using O_EXEC, which requires mode --x
- exec stage: fexecve() will not check mode --x on file descriptor

O_EXEC is mutually exclusive with O_RDONLY, O_WRONLY, or O_RDWR

It is worth noting that O_SEARCH works exactly the same way for other
exentended API set part 2 functions. Example with mkdirat():
Way 1:
- open stage: openat() using O_RDONLY, O_WRONLY, or O_RDWR
- exec stage: mkdirat() will check --x mode on file descriptor

Way 2:
- open stage: openat() using O_SEARCH, which requires mode --x
- exec stage: mkdirat() will not check mode --x on file descriptor

O_SEARCH is mutually exclusive with O_RDONLY, O_WRONLY, or O_RDWR. Since
O_EXEC is to be used on files and O_SEARCH is to be used on directories,
they may have the same binary value.


Does everyone agrees on this interpretation? If we do, next steps are
- describe threats this introduce to chrooted processes
- decide if they are acceptable and if they are not, propose mitigation.


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost