Re: [PATCH 1/3] Add a new exec_exec_file_name RPC

[Samuel Thibault]

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