On 07.11.2017 00:54, Christos Zoulas wrote:
> On Nov 7, 12:23am, n54%gmx.com@localhost (Kamil Rytarowski) wrote:
> -- Subject: Re: Fixing $ORGIN RPATHs - at least some of them
>
> | Can we kill vnode_to_path() from sys/uvm/uvm_map.c? This one is
> | problematic in existing software. There is need to alter programs using
> | sanitizer to not break (shorten filenames). This perhaps would mean to
> | attach a path name to a vnode entry.
>
> What do you mean? Which program requires the map object entry filenames
> to be there?
>
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.
> | How to deal with resolution of the exec name under chroot (program
> | called chroot(2) during execution)? I think that returning the original
> | path might be wrong.
> |
> | 1. Return failure (ENOTSUP?).
> | 2. Check if the exe path is under chroot and if so, normalize to chroot
> | prefix.
>
> This is already done correctly. The execed path is the chrooted path.
> I.e. you can't exec something outside the chroot from inside the chroot...
>
> christos
>
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'
Attachment:
signature.asc
Description: OpenPGP digital signature