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

[Emilio Pozuelo Monfort]

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

                 Summary: execve(path, args) should take path as a a relative
path if it doesn't contain slashes
                 Project: The GNU Hurd
            Submitted by: pochu
            Submitted on: Fri 19 Feb 2010 03:43:23 PM GMT
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Standard Compliance
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Reproducibility: Every Time
              Size (loc): None
         Planned Release: None
                  Effort: 0.00
Wiki-like text discussion box: 

    _______________________________________________________

Details:

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.




    _______________________________________________________

Reply to this item at:

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

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