Los gurús dicen que LD_LIBRARY_PATH es malo, ¿cuál es la alternativa?

Question

He leído algunos artículos sobre problemas en el uso del LD_LIBRARY_PATH, incluso como parte de un guión envoltorio:

http://linuxmafia.com/faq/Admin/ld-lib-path.html

http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the

En este caso - ¿cuáles son las alternativas recomendadas?

Gracias.

Answer 1

Siempre he configurado LD_LIBRARY_PATH, y nunca he tenido un problema.

de darles primer enlace:

Cuando debería establecer LD_LIBRARY_PATH? La respuesta corta nunca es. ¿Por qué? Algunos usuarios parecen configurar esta variable de entorno debido a los malos consejos de otros usuarios o al código mal vinculado que no saben cómo solucionarlo.

Eso es NO lo que llamo un planteamiento del problema definitiva. De hecho, me viene a la mente I don't like it. [YouTube, pero SFW].

---

Esa segunda entrada de blog (http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the) es mucho más próxima a la naturaleza del problema ... que parece ser, en pocas palabras, versión de la biblioteca choca ThisProgram requiere Foo1.2, pero requiere ThatProgram foo1. 3, por lo tanto, no puede ejecutar ambos programas (fácilmente). Tenga en cuenta que la mayoría de estos problemas son negados por una simple secuencia de comandos contenedora que establece LD_LIBRARY_PATH solo para el shell de ejecución, que es (casi siempre) un proceso secundario independiente de shell interactivo.

Tenga en cuenta también que las alternativas están bastante bien explicadas en la publicación.

Estoy confundido acerca de por qué publicaría una pregunta que contiene enlaces a artículos que aparentemente responden a su pregunta ... ¿Tiene una pregunta específica que no estaba cubierta (lo suficientemente clara) en ninguno de esos artículos?

Answer 2

la respuesta está en el primer artículo que citó.

En UNIX, la ubicación de una biblioteca se puede especificar con la opción -L dir para el compilador. .... Como alternativa al uso de las opciones -L y -R, puede establecer la variable de entorno LD_RUN_PATH antes de compilar el código.

Answer 3

Usted puede tratar de añadir:

-Wl,-rpath,path/to/lib 

a las opciones del vinculador. Esto le ahorrará la necesidad de preocuparse por la variable de entorno LD_LIBRARY_PATH, y puede decidir al compilar el tiempo para apuntar a una biblioteca específica.

Para una ruta relativa al binario, puede utilizar $ ORIGEN, por ejemplo

-Wl,-rpath,'$ORIGIN/../lib' 

($ ORIGEN puede no funcionar cuando se vincula estáticamente a las bibliotecas compartidas con dificultades de aprendizaje, utilice -Wl, - permitir-shlib -undefined de solucionar este problema)

Answer 4

me parece que las respuestas existentes para hacer realidad responden a la pregunta de una manera directa:

1. LD_RUN_PATH es utilizado por el enlazador (ver ld) en el momento de vincular su software. Se usa solo si no tiene -rpath ... en la línea de comando (-Wl,rpath ... en la línea de comando gcc). La (s) ruta (s) definida (s) en esa variable se agregan a la entrada RPATH en su archivo binario ELF. (Se puede ver que rPath usando objdump -x binary-filename -en la mayoría de los casos no es allí, sin embargo! Aparece en mis binarios de desarrollo, pero una vez que la versión final se instala RPATH consigue quitado.)

2. LD_LIBRARY_PATH se utiliza en tiempo de ejecución, cuando se desea especificar un directorio que el vinculador dinámico (consulte ldd) necesita buscar bibliotecas. Especificar la ruta incorrecta podría llevar a cargar las bibliotecas incorrectas. Esto se utiliza además del valor RPATH definido en su binario (como en 1.)

LD_RUN_PATH realmente provoca ninguna amenaza de seguridad a menos que seas un programador y no sabe cómo usarlo. Como estoy usando CMake para construir mi software, el -rpath se usa todo el tiempo. De esa forma no tengo que instalar todo para ejecutar mi software. ldd puede encontrar todos los archivos .so de forma automática. (Se suponía que el entorno automake también lo haría, pero no era muy bueno en comparación).

LD_LIBRARY_PATH es una variable de tiempo de ejecución y por lo tanto hay que tener cuidado con ella. Dicho esto, muchos objetos compartidos serían realmente difíciles de tratar si no tuviéramos esa característica especial. Si se trata de una amenaza a la seguridad, probablemente no. Si un pirata informático se apodera de su computadora, LD_LIBRARY_PATH es accesible para ese hacker de todos modos. Lo que podría suceder es que use la (s) ruta (s) incorrecta (s) en esa variable, su binario no se cargue, pero si se carga puede terminar con un binario bloqueado o al menos un binario que no funciona del todo bien. Una preocupación es que con el tiempo obtendrá nuevas versiones de la biblioteca y es probable que se olvide de eliminar el LD_LIBRARY_PATH, lo que significa que puede estar utilizando una versión no segura de la biblioteca.

La otra posibilidad de seguridad es si el pirata informático instala una biblioteca falsa del mismo nombre que busca el binario, biblioteca que incluye todas las mismas funciones, pero que tiene algunas de esas funciones reemplazadas por código furtivo. Él puede cargar esa biblioteca cambiando la variable LD_LIBRARY_PATH. Entonces eventualmente será ejecutado por el pirata informático. Nuevamente, si el pirata informático puede agregar una biblioteca de ese tipo a su sistema, él ya ingresó y probablemente no necesite hacer nada de eso en primer lugar (ya que tiene control total de su sistema). Porque en realidad, si el hacker solo puede colocar la biblioteca en su cuenta, no hará mucho (a menos que su caja Unix no sea segura en general ...) Si el hacker puede reemplazar una de sus bibliotecas /usr/lib/..., ya tiene acceso completo a su sistema. Por lo tanto, LD_LIBRARY_PATH no es necesario.