[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fexecve, round 2
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.
David A. Holland
Main Index |
Thread Index |