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