LD_PRELOAD afecta nuevo niño, incluso después de unsetenv ("LD_PRELOAD")

Question

mi código es el siguiente: preload.c, con el siguiente contenido:

#include <stdio.h> 
#include <stdlib.h> 

int __attribute__((constructor)) main_init(void) 
{ 
    printf("Unsetting LD_PRELOAD: %x\n",unsetenv("LD_PRELOAD")); 
    FILE *fp = popen("ls", "r"); 
    pclose(fp); 
} 

a continuación en la cáscara (hacer el segundo comando con cuidado !!):

gcc preload.c -shared -Wl,-soname,mylib -o mylib.so -fPIC 
    LD_PRELOAD=./mylib.so bash 

!!! tenga cuidado con el último comando que resultará con un bucle infinito de bifurcación "sh -c ls". Deténgalo después de 2 segundos con^C, (o mejor^Z y luego vea ps).

Más información

1. Este problema se refieren a golpear de alguna manera; ya sea como el comando que el usuario ejecuta, o como el bash que ejecuta el popen.
2. adicionales Factores clave: 1) realizar el popen desde la biblioteca precargada, 2) probablemente necesite hacer el popen en la sección de inicialización de la biblioteca.

3. si utiliza:

   LD_DEBUG=all LD_DEBUG_OUTPUT=/tmp/ld-debug LD_PRELOAD=./mylib.so bash 
   

   en lugar del último comando, recibirá muchos archivos ld-depuración, llamado /tmp/ld-debug.*. Uno para cada proceso bifurcado. EN TODOS ESTOS ARCHIVOS verá que los símbolos se buscan por primera vez en mylib.so aunque LD_PRELOAD se eliminó del entorno.

Answer 1

edición: por lo que el problema/pregunta en realidad era: howcome no puede desarmaste LD_PRELOAD de manera confiable usando un main_init() precargado desde bash.

La razón es que execve, que se llama después de que popen, lleva el medio ambiente de (probablemente)

extern char **environ; 

que es un poco variable de estado global que apunta a su medio ambiente. unsetenv() normalmente modifica su entorno y, por lo tanto, tendrá un efecto sobre los contenidos de **environ.

Si bash trata de hacer algo especial con el medio ambiente (bueno ... ¿sería un caparazón?) Entonces puede que tenga problemas.

Aparentemente, bash sobrecarga unsetenv() incluso antes de main_init(). Cambiar el código de ejemplo a:

extern char**environ; 

int __attribute__((constructor)) main_init(void) 
{ 
int i; 
printf("Unsetting LD_PRELOAD: %x\n",unsetenv("LD_PRELOAD")); 
printf("LD_PRELOAD: \"%s\"\n",getenv("LD_PRELOAD")); 
printf("Environ: %lx\n",environ); 
printf("unsetenv: %lx\n",unsetenv); 
for (i=0;environ[i];i++) printf("env: %s\n",environ[i]); 
fflush(stdout); 
FILE *fp = popen("ls", "r"); 
pclose(fp); 
} 

muestra el problema. En carreras normales (que se ejecuta cat, ls, etc) me sale esta versión de unsetenv:

unsetenv: 7f4c78fd5290 
unsetenv: 7f1127317290 
unsetenv: 7f1ab63a2290 

embargo

, correr o bashsh:

unsetenv: 46d170 

Así que, ahí lo tienen. bash te tiene engañado ;-)

Así que basta con modificar el medio ambiente en su lugar con su propio unsetenv, que actúa sobre **environ:

for (i=0;environ[i];i++) 
{ 
    if (strstr(environ[i],"LD_PRELOAD=")) 
    { 
     printf("hacking out LD_PRELOAD from environ[%d]\n",i); 
     environ[i][0] = 'D'; 
    } 
} 

que puede verse a trabajar en el strace:

execve("/bin/sh", ["sh", "-c", "ls"], [... "DD_PRELOAD=mylib.so" ...]) = 0 

QED

Answer 2

(La respuesta es una pura especulación, y puede haber es incorrecto).

Tal vez, cuando realiza el proceso, el contexto de las bibliotecas cargadas persiste. Por lo tanto, mylib.sose cargó cuando invocó el programa principal a través de LD_PRELOAD. Cuando desarmaba la variable y bifurcaba, no se cargaba de nuevo; sin embargo, ya se ha cargado en el proceso principal. Tal vez, debes descargarlo explícitamente después de bifurcar.

También puede intentar "degradar" símbolos en mylib.so. Para ello, vuelva a abrirlo a través dlopen con banderas que lo colocan al final de la cola de símbolo resolución:

dlopen("mylib.so", RTLD_NOLOAD | RTLD_LOCAL); 

Answer 3

¡la respuesta de mvds es incorrecta!

popen() generará un proceso hijo que hereda el archivo .so cargado previamente en el proceso principal. a este proceso hijo no le importa el entorno LD_PRELOAD.