Re: Fixing $ORGIN RPATHs - at least some of them

[christos%astron.com@localhost (Christos Zoulas)]

In article <81dc9d96-1d6a-9293-aa26-c5b92139d99b%gmx.com@localhost>,
Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 07.11.2017 15:47, Christos Zoulas wrote:
>> On Nov 7,  1:19am, n54%gmx.com@localhost (Kamil Rytarowski) wrote:
>> -- Subject: Re: Fixing $ORGIN RPATHs - at least some of them
>> 
>> | For the program name we could reuse this new variable.
>> | 
>> | $ cat /proc/curproc/maps|head -3
>> | 0000000035400000-0000000035402000 r-xp 0000000000000000 00:00 91906
>> |                         /bin/cat
>> | 0000000035602000-0000000035603000 r--p 0000000000002000 00:00 91906
>> |                         /bin/cat
>> | 0000000035603000-0000000035604000 rw-p 0000000000000000 00:00 0
>> | 
>> | If the variable is problematic in the given environment, we get errors.
>> 
>> This is a very complicated way to get the program name (but the process
>> maps). The maps are useful for other things...
>> 
>> | I mean code like this:
>> | 
>> | http://netbsd.org/~kamil/execpath.c
>> | 
>> | In the current implementation I'm getting the following questionable result:
>> | 
>> | $ sudo ./a.out
>> | cwd='/'
>> | execname='/tmp/a.out'
>> | Cannot stat '/tmp/a.out'
>> 
>> Yes, this is a very special case and if we fix it, it can actually
>> fail if you chroot in a tree that's outside the tree the original
>> executable was executed from. Nevertheless, while it can be fixed,
>> we have bigger fish to fry.
>> 
>> christos
>> 
>
>Right, if we fix now the correct resolution of programs with hardlink,
>it will be already a big step forwards! The rest of use-cases can be
>fixed later.

You mean use a hardlink in /proc/pid/exe instead of a symlink?

christos