In che modo il chroot influisce sul collegamento dinamico?

Question

Ecco lo scenario che sto avendo:

Ho creato un ambiente debootstrap ubuntu maverick (64-bit). L'ho posizionato a /env/mav/ sul mio sistema lucido Ubuntu (64 bit). Posso chroot in /env/mav e posso utilizzare perfettamente un sistema anticonformista.

Posso perfino usare i programmi lucidi anche al di fuori dell'ambiente chroot. Questo è /env/mav/bin/ls verrà eseguito.

Tuttavia, ho notato che se modifico LD_LIBRARY_PATH di essere /env/mav/lib [1] [2]

ogni singolo programma (sia lucido e anticonformista) corro in crash immediatamente. (ad esempio, ls ha come risultato un segfault). kern.log mostra:

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

Tuttavia, chiaramente se chroot in /env/mav, ogni programma sta funzionando benissimo. E non tutte le biblioteche vengono lette dal carcere (/env/mav) /lib? Quindi qual è la differenza tra chroot e la modifica di LD_LIBRARY_PATH in questo contesto?

Inoltre, se io:

mount -B /env /env/mav/env 

e quindi chroot /env e quindi impostare LD_LIBRARY_PATH di essere /env/mav/lib, tutto funziona ancora bene.

Sono a corto per ciò che sta accadendo internamente qui. Ci sono alcuni diari interni memorizzati da qualche parte? Chroot fa qualcosa di magico?

[1] Il caso di utilizzo consente di eseguire programmi dall'ambiente maverick vincolato correttamente a librerie di linker dinamicamente esternamente al di fuori della prigione anticonformista.

[2] Questo è solo un esempio abbreviato. In realtà /usr/lib, ecc. Sono tutti inclusi. Compreso tutto il "ambiente velenoso" dell'ambiente/libativo dell'ambiente; non ci sono problemi nell'usare le altre directory di libreria maverick.

Answer 1

LD_LIBRARY_PATH è l'opzione del programma/libreria ld-linux.so. Questa libreria è un linker di Dynamick. Il suo percorso "/lib/ld-linux.so.2" è codificato in (quasi) tutti i programmi collegati dinamicamente in ubuntu, nell'intestazione ELF (campo INTREP). Intendo dire che, quando il kernel di Linux esegue un file binario, non sa nulla del significato speciale di LD_LIBRARY_PATH.

Così, quando si esegue

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

/lib/ld-linux.so.2 del sistema radicale sarà utilizzato e poi si cercherà di risolvere le librerie dinamiche utilizzando $LD_LIBRARY_PATH variabile ENV (si può vedere ciò che è goind using LD_DEBUG=all variabile env)

E quando si esegue un chroot, verrà utilizzato lo /lib/ld-linux.so.2 di Maverick.

credo, non ci può essere qualche dell'incompatibilità tra il sistema del sistema host e guest ld-linux (Maverick) libc.so (perché LD-linux è parte del pacchetto glibc/EGLIBC e utilizza qualcosa da libc.so).

per testare la mia ipotesi, provare a correre (sintassi bash di regolazione variabile ENV):

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

Qui provo a iniziare ld-linux ospite manualmente, al fine di sovrascrivere percorso INTREP hardcoded (Sì, questo sembra piuttosto insolito eseguire una libreria .so, ma questa libreria è il caso molto speciale e consente questa sintassi). Se questo comando funzionerà, la mia ipotesi potrebbe essere buona. Altrimenti, ci sono altre spiegazioni possibili.