* Kees Cook: > On Fri, May 15, 2020 at 10:43:34AM +0200, Florian Weimer wrote: >> * Kees Cook: >> >> > Maybe I've missed some earlier discussion that ruled this out, but I >> > couldn't find it: let's just add O_EXEC and be done with it. It actually >> > makes the execve() path more like openat2() and is much cleaner after >> > a little refactoring. Here are the results, though I haven't emailed it >> > yet since I still want to do some more testing: >> > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/o_exec/v1 >> >> I think POSIX specifies O_EXEC in such a way that it does not confer >> read permissions. This seems incompatible with what we are trying to >> achieve here. > > I was trying to retain this behavior, since we already make this > distinction between execve() and uselib() with the MAY_* flags: > > execve(): > struct open_flags open_exec_flags = { > .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, > .acc_mode = MAY_EXEC, > > uselib(): > static const struct open_flags uselib_flags = { > .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, > .acc_mode = MAY_READ | MAY_EXEC, > > I tried to retain this in my proposal, in the O_EXEC does not imply > MAY_READ: That doesn't quite parse for me, sorry. The point is that the script interpreter actually needs to *read* those files in order to execute them. Thanks, Florian