Re: exec server and /dev/fd/N

[Carl Fredrik Hammar]

On Wed, May 26, 2010 at 12:29:06PM +0200, Emilio Pozuelo Monfort wrote:
> On 26/05/10 09:32, olafBuddenhagen@gmx.net wrote:
> > On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
> > 
> >> Basically the problem is that in some cases the exec server can't find
> >> the file name of the file being executed (when it's a script), and
> >> then makes a hack passing /dev/fd/N to the interpreter.
> >>
> >> I tried to fix it with heuristics such as "if the file name contains
> >> no slashes, then it's relative" and passing just a flag to the exec
> >> server to avoid needing to create new RPCs, but that's not enough,
> >> since a call like execv("foo",{"bar", NULL}) (i.e. filename !=
> >> argv[0]) should work too. So the only option is to pass filename to
> >> the exec server, and just use that.
> > 
> > IIRC my major concern with this approach was that this way, the original
> > task has to guess what file name will be valid in the new task's
> > context... I don't remember though what my conclusion was regarding this
> > being better or worse than doing the guessing in exec :-(
> 
> The point is that the original task doesn't need to do any guessing, since it
> knows the file name. It's the one it's used to lookup the file_t. From all the
> places that use _hurd_exec or file_exec, there's only one I haven't been able 
> to
> determine filename, and that's fexecve().

It is possible for a client to open a file but send a different root
to the new task.  This is a pretty contrived situation but there might
be cases we're missing.  For instance, in fexecve() you could send a
"/dev/fd/N" path but if that file descriptor is O_CLOEXEC it would be
closed once the program is running.

But since exec still checks that the identity ports are the same and
falls back to using a "/dev/fd/N" path (to a new FD) in that case, it
is almost impossible to end up with the wrong file.  The only case it
can happen is if the filesystem is malicious and returns someone else's
identity port, but this is possible with the current implementation as
well, and I doubt it can be exploited.

Regards,
  Fredrik