[bug #28934] execve(path, args) should take path as a a relative path if it doesn't contain slashes

[Carl Fredrik Hammar]

Follow-up Comment #4, bug #28934 (project hurd):

I researched further how argv[0] is supposed to be handled and have a
much firmer grasp on the situation now.

argv[0] is only expanded to path to the executed file when the executed
file is a #!-script.  This means that touching argv[0] in execve()
is not acceptable because we don't know that at this point.

The reason argv[0] is expanded is because it is passed as an argument
to the interpreter, otherwise the interpreter can't find it.

Because the exec server is passed an already opened port to the
executable, it doesn't know the path used to open the executable.
It has to reconstruct it instead.

Also, ``./foo bar'' gets me `bar' in Linux not `./bar'.  Are you sure
you got `./bar' in this case?

> Actually I don't think the exec server needs to know what exec*() variant
> has been called, since the call itself will have called execve() with
> the full path by looking at PATH if needed (see glibc's posix/execvpe.c,
> the beginning of the do-while() loop around line 140).

As explained above, the full path isn't sent to the exec server.

> Anyway since that may be an implementation detail and since I don't
> know if changing the exec server to stop looking at $PATH if the file
> doesn't contain an slash will break other stuff, changing execve()
> as you propose sounds like a good idea.

It turns out my idea was rubbish.  :-)

> Another similar option is to prepend . to $PATH in that case (and then
> the exec server will prepend ./ to the file).

This isn't a good idea either since the child process will end up with
a different $PATH as a side-effect.

> I'm going to prepare and test a patch for one of the two options.

Sorry for pointing you in the wrong direction. :-(

I now think a better solution is to change the exec server to look in
the current directory for the file.

The question is whether this is secure, and I'd say `yes' simply
because the path reconstruction seems pretty haphazardous as it is.
While the exec server does do some tests on the file with io_identity,
it is pretty easy for a file to fake this information, and I suspect this
is the reason the exec server only tries to reconstruct the path if the
EXEC_SECURE flag is off.  To be on the safe side the current directory
should be checked after $PATH.

Please do this instead.

A final solution might be to change the exec protocol so that exec*()
can pass on the files path, which seems much more robust.  Or possibly
do the checking for #!-scripts in glibc...  But you don't have to worry
about this, unless you want to of course.  :-)

Regards,
  Fredrik

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?28934>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/