Re: fexecve, round 2

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost