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.nore...@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
