Hello,
Roland, could you have a look? This is really posing problems.
Samuel Thibault, le Fri 11 Apr 2014 09:03:03 +0200, a écrit :
As a reminder, here is the issue:
“
$ cat bar
#!/bin/sh
echo "\$0: $0"
$ cat foo.c
...
char *arg[] = { argv[1], NULL };
execv (*arg, arg);
perror ("execv");
...
$ ./foo ./bar
$0: ./bar
$ ./foo bar
$0: /dev/fd/3
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.
”
as well as other issues met here and there in Debian packages. We just
won't be able to manage to convince glib that they can not do this, and
Debian will keep insisting on running the testsuite of course.
Roland McGrath, le Tue 01 Jun 2010 16:22:57 -0700, a écrit :
> I am not convinced that this is worth doing.
Well, it has already been done, why not integrating it? Not having it
upstream is giving us downstream pain.
> Any name from anywhere is always just a guess at what might be the
> right file name.
Err, not really here: the idea is to make glibc pass the filename it has
used to open the file. This is not a guess any more, this just reflects
reality.
> It is only a guess for convenience when not secure, after all.
But with this RPC extension, this is not a guess any more in cases where
it can not be one.
> There will always be cases where you can't manage to guess it.
> With fexecve, there isn't even any
> such file name to pass as a better guess than something derived from argv[0].
Sure, but in that case users will not even try to get a name from
argv[0], while in the ./foo bar case, I believe they are rightful in
thinking they can get a name from argv[0].
Samuel
