¿Cuál es el orden en que el enlazador dinámico de Linux busca rutas?

Esto no es un duplicado porque se trata de una peculiaridad que noté cuando la uso /etc/ld.so.conf.

Para obtener las rutas en las que el enlazador dinámico busca bibliotecas, ejecuto el comando ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". Cuando /etc/ld.so.confno tiene rutas enumeradas en él. El resultado del comando anterior es

/lib
/usr/lib

Pensé que busca /libprimero y luego /usr/lib. Cuando agrego una nueva ruta, como /usr/local/lib, a /etc/ld.so.confy luego rehacer /etc/ld.so.cache, la salida de se ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"convierte en

/usr/local/lib
/lib
/usr/lib

Esto me parece extraño porque si estoy en lo cierto, el orden en que se buscan los directorios enumerados es de arriba a abajo, entonces se buscan directorios adicionales antes /liby /usr/lib. Que los directorios adicionales se busquen antes que los directorios de confianza no es extraño por sí solo, pero cuando /libse busca antes /usr/lib, eso es extraño porque /bin& /sbinse busca después /usr/bin& /usr/sbinadentro PATH.

Incluso si las rutas enumeradas por ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"se buscaran de abajo hacia arriba, seguiría siendo un orden sesgado porque se buscarían directorios adicionales después de los de confianza mientras se /libbuscarían /usr/lib.

Entonces, ¿cuál es el orden en el que ld.sobusca rutas en las bibliotecas? ¿Por qué se /libbusca antes /usr/lib? Si no es así, ¿por qué se buscan directorios adicionales /lib?

El orden está documentado en el manual del enlazador dinámico, que es ld.so. Es:

1. directorios de LD_LIBRARY_PATH;
2. directorios de /etc/ld.so.conf;
3. /lib;
4. /usr/lib.

(Estoy simplificando un poco, consulte el manual para obtener todos los detalles).

El orden tiene sentido cuando considera que es la única forma de anular una biblioteca en una ubicación predeterminada con una biblioteca personalizada. LD_LIBRARY_PATHes una configuración de usuario, tiene que venir antes que los demás. /etc/ld.so.confes una configuración local, viene antes del valor predeterminado del sistema operativo. Entonces, como usuario, si quiero ejecutar un programa con una versión diferente de una biblioteca, puedo ejecutar el programa que LD_LIBRARY_PATHcontiene la ubicación de esa versión de biblioteca diferente. Y como administrador, puedo poner una versión diferente de la biblioteca en /usr/local/liby la lista /usr/local/libde /etc/ld.so.conf.

La confianza no entra en esto. Se debe confiar en cualquier directorio listado en esta ruta de búsqueda, porque cualquier biblioteca podría terminar cargándose desde allí. En teoría, podría enumerar los nombres de biblioteca utilizados por todos los programas que "requieren más confianza" en su sistema y asegurarse de que todas estas bibliotecas estén presentes en los directorios "más confiables", y luego los directorios "menos confiables" no se utilizará si vinieron después de los directorios más confiables en la ruta de búsqueda, a excepción de los programas "que requieren menos confianza". Pero eso sería extremadamente frágil. También sería bastante inútil: si un atacante puede inyectar un valor LD_LIBRARY_PATHo un elemento de /etc/ld.so.conf, seguramente tiene una ruta más directa para ejecutar código arbitrario, como inyectar un valor de PATH, deLD_PRELOAD, etc. La confianza en la ruta de carga de la biblioteca es importante cuando la ejecución cruza un límite de confianza, es decir, cuando se ejecuta un programa con privilegios adicionales (por ejemplo, programa setuid / setgid, o vía sudo). Lo que sucede en este caso es que LD_LIBRARY_PATHqueda en blanco.

En cuanto a /libvs /usr/lib, no importa mucho: son proporcionados por la misma entidad (el sistema operativo) y no debería haber una biblioteca que esté presente en ambos. Tiene sentido enumerar /libprimero porque proporciona una ventaja de rendimiento (muy pequeña): las bibliotecas más utilizadas, especialmente las bibliotecas utilizadas por pequeños programas básicos (para los cuales el tiempo de carga es una fracción mayor del tiempo de ejecución total que el largo, largo -programa de ejecución), se encuentran en /lib.