Não é possível chroot bash após configurar RUNPATH em ld-linux-x86-64.so.2 com patch-up de 0,6 e 0,8

Question

Estou testando como a vinculação dinâmica funciona com a variável RUNPATH e tentando executar bash em um diretório chroot mínimo:

$ find dir_chroot/ -type f
dir_chroot/bin/bash
dir_chroot/lib/x86_64-linux-gnu/libc.so.6
dir_chroot/lib/x86_64-linux-gnu/libdl.so.2
dir_chroot/lib/x86_64-linux-gnu/libtinfo.so.5
dir_chroot/lib64/ld-linux-x86-64.so.2

- são todas dependências de bash e são binários reais ( find -type f ), não links simbólicos. Além disso, eles não têm RUNPATH :

$ find dir_chroot/ -type f -exec sh -c "readelf -d {} | grep RUNPATH" \;
$ 

chroot funciona bem com este diretório:

$ sudo chroot dir_chroot /bin/bash
bash-4.3# exit
exit

No entanto, se eu copiar tudo e definir RUNPATH para $ORIGIN/ em lib64/ld-linux-x86-64.so.2 , recebo o código de saída 139 ( segfault ?) ao executar chroot :

$ cp -R dir_chroot dir_chroot4
$ find dir_chroot4/ -type f -exec sh -c "echo {} 'readelf -d {} | grep RUNPATH'" \; 
dir_chroot4/bin/bash
dir_chroot4/lib/x86_64-linux-gnu/libc.so.6
dir_chroot4/lib/x86_64-linux-gnu/libdl.so.2
dir_chroot4/lib/x86_64-linux-gnu/libtinfo.so.5
dir_chroot4/lib64/ld-linux-x86-64.so.2
$
$ patchelf --set-rpath "\$ORIGIN/" dir_chroot4/lib64/ld-linux-x86-64.so.2
$ find dir_chroot4/ -type f -exec sh -c "echo {} 'readelf -d {} | grep RUNPATH'" \; 
dir_chroot4/bin/bash
dir_chroot4/lib/x86_64-linux-gnu/libc.so.6
dir_chroot4/lib/x86_64-linux-gnu/libdl.so.2
dir_chroot4/lib/x86_64-linux-gnu/libtinfo.so.5
dir_chroot4/lib64/ld-linux-x86-64.so.2 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/]
$
$ sudo chroot dir_chroot4 /bin/bash
$
$ echo $status
139

- $status é a variável de status em fish shell.

Isso acontece somente se ld-linux-x86-64.so.2 for corrigido, outras bibliotecas e bash executável funcionarem ok com RUNPATH . Por que isso acontece?

    

Answer 1

Aparentemente, ld-linux-x86-64.so.2 está vinculado estaticamente, pelo menos no meu sistema:

>ldd ld-linux-x86-64.so.2
statically linked

ao contrário de libc.so.6 , libdl.so.2 e libtinfo.so.5

>ldd libc.so.6 libdl.so.2 libtinfo.so.5

libc.so.6:
/lib64/ld-linux-x86-64.so.2 (0x000056469847a000)
linux-vdso.so.1 =>  (0x00007ffe95185000)

libdl.so.2:
linux-vdso.so.1 =>  (0x00007fffc4718000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa1df136000)
/lib64/ld-linux-x86-64.so.2 (0x0000558334a9c000)

libtinfo.so.5:
linux-vdso.so.1 =>  (0x00007ffe1b7bd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffa990b9000)
/lib64/ld-linux-x86-64.so.2 (0x00005590bfced000)

que faz o carregador ficar louco e resultar em um segfault, quando você injetar RUNPATH nele forçadamente.