Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

[Rich Felker]

On Sat, Jan 10, 2015 at 04:14:57AM +0000, Al Viro wrote:
> On Fri, Jan 09, 2015 at 10:41:44PM -0500, Rich Felker wrote:
> > > _After_ the traversal it's too late to do this sort of thing - after all,
> > > how do you tell if your current position had been set by the traversal of
> > > your symlink or that of any normal /proc/self/fd/<n>?
> > 
> > Thanks for clarifying how this all works in the kernel. It makes it
> > easier to understand what the costs (especially complexity costs) of
> > different implementation options might be for the kernel.
> > 
> > > And doing that _during_ the traversal would really suck - stray ls -lR /proc
> > > could race with that open() done by script interpreter.
> > 
> > IMO this one issue is easily solvable by limiting the special action
> > to calls by the owning pid.
> 
> Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
> etc.) before bothering with open(2), you'll get screwed.

Yes, but I think that would be very bad interpreter design.
stat/getxattr/access/whatever followed by open is always a TOCTOU
race. The correct sequence of actions is always open followed by
fstat/fgetxattr/...

> Moreover, if it
> does so only in case when you have something specific in environment,
> you'll have the devil of the time trying to figure out how to reproduce
> such a bug report...

Yes, this is a more serious concern. For example, if a shell processes
$HISTFILE or something before opening the script. I'm starting to
prefer the idea of just refusing to honor the close-on-exec flag for
the fd passed to fexecve but preserving it, and letting the
interpreter close the file itself if it wants to. This could be done
with or without the new auxv entry stuff.

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/