[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 #6, bug #28934 (project hurd):

> > The reason argv[0] is expanded is because it is passed as an argument
> > to the interpreter, otherwise the interpreter can't find it.
> 
> Unless it is a relative path, of course.

I did mean any path, relative or not.  What's important is that e.g. `ps'
expands to `/bin/ps' instead of non-existent file `ps'.

> >> 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.
> 
> But since all of exec() go are wrappers around execve(), and execve()
> opens the path passed to it without looking at $PATH, and then passes
> it to the exec server as is, we can assume the path in argv[0] is
> the same one that was used to open the port, and that it's either a
> relative or an absolute path, and we don't need to look at $PATH at
> all. (That is for the exec() cases, I don't know for other things that
> use _hurd_exec()).

Normally, argv[0] is the same as the file argument to exec*(), so an
execvp("foo") will still have argv[0] = "foo", even if it results in
a execve("/bin/foo").  But note that this is just convention as argv[0]
can be an arbitrary string...

> > 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.
> 
> I'm not really convinced about looking in the current directory,
> although if we do, doing it after looking at $PATH sounds reasonable.

I agree that this is an unsatisfying solution, but I recommend that you do
this first before you start with a more extravagant solution.  Then we'll
have fixed the problem at hand even if the better solution gets stalled.

> > 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. :-)
> 
> Changing the exec server so that we can pass it the full path sounds
> like the best option to me. What would be the best way to do it? Maybe
> adding a new _hurd_exec_path(task, file, path, argv, envp) that avoids
> looking at $PATH?

Well, this is an extensive change.  You'll need to add a path parameter
to at least the following: _hurd_exec, file_exec, exec_exec, and change
all callers.

Giving them new names, e.g. _hurd_exec_path, might be a good idea to
avoid incompatibilities, but eventually we'll want to deprecate the
original versions.  I don't know how this should be handled in general;
you'll want to get a more authoritative answer from Thomas Schwinge,
or possibly Olaf Buddenhagen or Samuel Thibault.

But really, do the current directory lookup first.  :-)

Regards,
  Fredrik


    _______________________________________________________

Reply to this item at:

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

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