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

[Ivan Shmakov]

        [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.]

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

        I'm not sure what the standards say on that matter, either, but
        the GNU Libc manual reads:

--cut: (libc) Executing a File --
 -- Function: int execv (const char *FILENAME, char *const ARGV[])
     The `execv' function executes the file named by FILENAME as a new
     process image.

     The ARGV argument is an array of null-terminated strings that is
     used to provide a value for the `argv' argument to the `main'
     function of the program to be executed.  The last element of this
     array must be a null pointer.  By convention, the first element of
     this array is the file name of the program sans directory names.
     *Note Program Arguments::, for full details on how programs can
     access these arguments.
--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.

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

[...]

-- 
FSF associate member #7257

pgppA8mtwdGBB.pgp
Description: PGP signature