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 m...@netbsd.org
