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

[Carl Fredrik Hammar]

Hi,

On Fri, Feb 26, 2010 at 10:18:27PM +0600, Ivan Shmakov wrote:
>       [I've unsuccessfully tried to submit the comment via the Web
>       interface at http://savannah.gnu.org/bugs/, thus I'm posting it
>       to the list instead.]

No problem, people seem to mix the two all the time anyways.

> >>>>> Carl Fredrik Hammar <INVALID.NOREPLY@gnu.org> writes:
> 
> [...]
> 
>  > 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.
> 
>       I don't know the details on how it's done in Hurd, but shouldn't
>       the exec* () library functions pass the whole argv[] (including
>       argv[0]) to the server?

Yes, the whole argv[] is passed, but not the path to the file being
executed.  That is, for execv("/bin/foo", { "foo", ... }) the exec server
will get "foo" but not "/bin/foo", so it tries to deduce it from "foo".

> --cut: (libc) Executing a File --
> 
>       Please note that since FILENAME is a completely distinct
>       argument from ARGV, ARGV[0] may, most of the time, contain
>       garbage, without breaking the programs being called in any way.

This is the important part: we want FILENAME not ARGV[0].

>  > Also, ``./foo bar'' gets me `bar' in Linux not `./bar'. Are you sure
>  > you got `./bar' in this case?
> 
>       Perhaps, there was ‘.’ in the PATH's value?  (Which is known to
>       be a gigantic security hole, BTW.)

It turns out this was misreported by Emilio; he also got `bar'.

Regards,
  Fredrik