tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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


Home | Main Index | Thread Index | Old Index