¿Cómo afecta chroot a la vinculación dinámica?

Question

Aquí está el escenario que estoy teniendo:

He creado un entorno debootstrap ubuntu maverick (64-bit). Lo coloqué en /env/mav/ en mi sistema lúcido ubuntu (64 bits). Puedo chroot en /env/mav y puedo utilizar un sistema inconformista a la perfección.

Incluso puedo usar los programas lúcidos bien fuera del entorno chrooted. Eso es /env/mav/bin/ls se ejecutará.

Sin embargo, me di cuenta de que si modifico LD_LIBRARY_PATH sea /env/mav/lib [1] [2]

cada programa (tanto lúcido y Maverick) corro se colgará al instante. (por ejemplo, ls da como resultado una segfault). kern.log muestra:

segfault at 7fece284aa18 ip 00007fece284aa18 sp 00007fff32028158 error 15 

Sin embargo, con claridad si chroot en /env/mav, cada programa está funcionando muy bien. ¿Y no se están leyendo todas las bibliotecas de los encarcelados (/env/mav) /lib? Entonces, ¿cuál es la diferencia entre chroot y la modificación de LD_LIBRARY_PATH en este contexto?

Por otra parte, si:

mount -B /env /env/mav/env 

y luego chroot /env y luego configurar LD_LIBRARY_PATH a ser /env/mav/lib, todo lo que todavía funciona muy bien.

No entiendo lo que está pasando aquí. ¿Hay algún elemento interno ld almacenado en algún lugar? ¿Chroot hace algo mágico?

[1] El caso de uso es para ejecutar programas desde el entorno inconformista enlazado correctamente para disolver bibliotecas dinámicamente vinculadas fuera de la cárcel inconformista.

[2] Esto es solo un ejemplo abreviado. En realidad, /usr/lib, etc. están incluidos. Incluyendo los "venenos" del entorno inconformista/lib todo; no hay problemas al usar los otros directorios de la biblioteca Maverick.

Answer 1

LD_LIBRARY_PATH es la opción del programa ld-linux.so biblioteca. Esta biblioteca es un enlazador dynamick. Su ruta "/lib/ld-linux.so.2" está codificada en (casi) todos los programas enlazados dinámicamente en ubuntu, en el encabezado ELF (campo INTREP). Quiero decir que, cuando el kernel de Linux ejecuta un archivo binario, no sabe nada sobre el significado especial de LD_LIBRARY_PATH.

Por lo tanto, cuando se ejecuta

LD_LIBRARY_PATH=/env/mav/ /env/mav/bin/ls 

/lib/ld-linux.so.2 del sistema radicular será utilizada y entonces se tratará de resolver las bibliotecas dinámicas utilizando $LD_LIBRARY_PATH variable de entorno (se puede ver lo que está goind usando LD_DEBUG=all env variable)

Y cuando hagas un chroot, se usará /lib/ld-linux.so.2 de Maverick.

pienso, puede haber alguna incompatibilidad entre el sistema de de sistema anfitrión y el invitado ld-linux (Maverick) libc.so (porque ld-linux es parte del paquete de glibc/eglibc y utiliza algo de libc.so).

Para probar mi hipótesis, intente ejecutar (sintaxis fiesta de ajuste variable de entorno):

LD_LIBRARY_PATH=/env/mav/ /env/mav/lib/ld-linux.so.2 /env/mav/bin/ls 

Aquí intento iniciar ld-linux de los huéspedes de forma manual, con el fin de sobrescribir ruta INTREP hardcoded (Sí, esto parece bastante inusual ejecutar una biblioteca .so, pero esta biblioteca es el caso muy especial y permite esta sintaxis). Si este comando funciona, mi suposición puede ser buena. Si no, hay otras explicaciones posibles.