On Sat, Nov 17, 2012 at 06:42:50PM -0500, Thor Lancelot Simon wrote: > > O_EXEC cause open()/openat() to fail if the file mode does not grant > > execute rights > > > > There are security concerns with fd passed to chrooted processes, which > > could help executing code. Here is a proposal for chrooted processes: > > 1) if current process and executed vnode have different roots, then > > fexecve() fails > > 2) if the fd was not open with O_EXEC, fexecve() fails. > > This appears to contradict either the description of O_EXEC in the > standard, or the standard's rationale for adding fexecve(). The > standard says O_EXEC causes the file to be open for execution "only". > > In other words, O_EXEC means you can't read nor write the file. Now > the rationale for fexecve() doesn't hold, since you cannot read from > the fd, then exec from it without a reopen. > > Further, requiring O_EXEC would seem to directly contravene the > standard's language about fexecve()'s behavior.
The standard is clearly wrong on a number of points and doesn't match the historical design and behavior of Unix. Let's either implement something correct, or not implement it at all. > This to me is illustrative of the danger of slavishly substituting the > XPG group's technical judgment for our own. They frequently standardise > poorly thought out Linux hacks; twisting ourselves into knots to make > what they half-designed safe, at which point it doesn't conform to their > standard any more, does not seem like a good general plan to me. Indeed. -- David A. Holland dholl...@netbsd.org