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.
Attachment:
signature.asc
Description: OpenPGP digital signature