I've posted my last patches on http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html

The patch looks good, but I have a couple of suggestions.

In __execve you cannot just call _hurd_exec_file_name unconditionally
since all exec() variants end up as a __execve().  For instance,
if there is both `/bin/foo' and `./foo', execpv("foo", { "foo", 0 })
will expand to execve("/bin/foo", { "foo", 0 }, ...), which expands to
_hurd_exec_file_name(file, { "foo", 0 }, ...), which will make the exec
server think you meant `./foo'.  Instead, you should actually test with
strcmp whether FILE_NAME and ARGV[0] are one and the same.

Also I think you should have a flags argument to _hurd_exec_generic
instead of a boolean, pass along the EXEC_FILE_NAME flag, and
perhaps rename the function to _hurd_exec_flags.  You could even drop
_hurd_exec_file_name all together then, though you would have to move out
the #ifdef EXEC_FILE_NAME to the callers, so perhaps its worth keeping...

Regards,
  Fredrik

Err the glibc patch was not the one I finally used (I attached the wrong one). Here's the one I've used. I've tested in another VM and I see the same regression.

Furthermore I've found that gcc stops working fine in a machine with a new glibc.so and /hurd/exec (building my testcase fails because gcc can't find stddef.h), but that may be a consequence of the previous regression I mentioned.

It's indeed weird that it affects ELF binaries. I've looked if I could find something weird with the flags argument but everything looks right to me.

I'll try to debug the exec server with gdb to see what's going on. If you want to try this out, you can find the exec binary and libc.so on strauss.debian.net, on /home/pochu

(file #20202)

Actually there seems to be a regression:

a program like

main (int argc, char **argv)
{
  printf ("%s", argv[0]);
}

put into /bin/foobar, will make
$ foobar
print ./foobar instead of "foobar", which would be expected and works fine without my patches. I've looked at the patches and the Hurd code and I couldn't find why this would happen (I haven't debugged much yet as I couldn't attach gdb to the exec server).

> > 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

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

Hi Emilio,

I'm pretty sure you are correct in that execve() should not look in $PATH,
because glibc's sysdeps/mach/hurd/execve.c does a regular file lookup.
As you say the exec server gets confused since it does not find bar in
$PATH, and tries to reconstruct a `correct' path to the file.

The root problem is that the exec server can't tell which exec() variant
was called, so it doesn't know how to interpret argv[0].  The easiest
way to fix this is to prepend `./' to argv[0] if needed in execve().
This is probably the correct way to fix it as well.  I'm not sure if
this should be done to all relative paths or only ones that doesn't
contain slashes.  I'll leave it up to you to investigate further what
POSIX says about it and how Linux does it.

Regards,
  Fredrik

Hi,

I've been investigating the GLib test suite errors, and I've tracked them down to what looks like a glibc or a Hurd problem.

It looks like a call to execve() and co. don't take the "path" argument as a (relative) path if it doesn't contain any slashes. So a call like execve("foo", args) doesn't behave similarly to execve("./foo", args).

From my reading of POSIX, it seems to me that those system calls that have "path" as argument (and not "file" like e.g. execvp()) should take it as a path always, unlike "file", which should be understood as a path only when it contains an slash.

A test case would be like this:


hurd:/# cat bar
#!/bin/sh
echo "\$0: $0"

hurd:/# cat foo.c
#include <stdio.h>

int
main (int argc, char **argv)
{
  char *arg[] = { argv[1], NULL };

  execv (*arg, arg);
  perror ("execv");
  return 1;
}

hurd:/# ./foo ./bar
$0: ./bar

hurd:/# ./foo bar
$0: /dev/fd/3


On Linux I get ./bar in both cases (btw PATH must not contain . to reproduce the problem).

Part of the problem seems to be in check_hashbang() in hurd's exec/hashexec.c, where we have

              if (strchr (name, '/') != NULL)
                error = lookup (name, 0, &name_file);
              else if ((error = hurd_catch_signal
                        (sigmask (SIGBUS) | sigmask (SIGSEGV),
                         (vm_address_t) envp, (vm_address_t) envp + envplen,
                         &search_path, SIG_ERR)))
                name_file = MACH_PORT_NULL;

Here it takes name as a path only if it contains a slash, otherwise it looks for it in PATH (that's what search_path does).

Then after that it does:

          if (file_name == NULL)
            {
              /* We can't easily find the file.
                 Put it in a file descriptor and pass /dev/fd/N.  */

Having /dev/fd/N in $0 instead of the real file name is what is breaking libtool logic to find .libs and execute the correct binary, breaking GLib's test suite.

I'm not sure where this should be fixed, I guess in Hurd and/or in glibc. If someone can guide me a bit I'll try to cook a patch.