[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] Add a new exec_exec_file_name RPC
From: |
Samuel Thibault |
Subject: |
Re: [PATCH 1/3] Add a new exec_exec_file_name RPC |
Date: |
Fri, 11 Apr 2014 09:03:03 +0200 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
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
- Re: [PATCH 1/3] Add a new exec_exec_file_name RPC,
Samuel Thibault <=