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

[Ivan Shmakov]

>>>>> Carl Fredrik Hammar <INVALID.NOREPLY@gnu.org> writes:

[...]

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

        FWIW, this seems to be the most reasonable solution to me.

        But note that there's a slight terminology issue here:

--cut: (standards) GNU Manuals --
   Please do not use the term "pathname" that is used in Unix
documentation; use "file name" (two words) instead.  We use the term
"path" only for search paths, which are lists of directory names.
--cut: (standards) GNU Manuals --

 > but eventually we'll want to deprecate the original versions.

        Do I understand it correctly that the filename is only necessary
        when the exec server is called to execute a #! script?  If so,
        could there be uses for non-file name versions of these calls?
        These versions, however, should at some point of time be amended
        to fail when asked to execute a script.

        (Though I could imagine that these versions may be found to have
        only marginal uses, and so be discarded entirely.)

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

        Well, I think that no one will object to the OP patching the
        version in his own Git repository?  Anyway, the solution should
        be tested with respect to the original problem.

 > But really, do the current directory lookup first.  :-)

-- 
FSF associate member #7257

pgplhmX0_0c5O.pgp
Description: PGP signature