linux - raspberry - ld_library_path windows

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

Question

Leí algunos artículos sobre problemas en el uso de LD_LIBRARY_PATH, incluso como parte de un script contenedor:

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

Encuentro que las respuestas existentes para responder realmente la pregunta de una manera directa:

1. LD_RUN_PATH es utilizado por el enlazador (vea ld ) en el momento en que vincula su software. Se usa solo si no tiene -rpath ... en la línea de comandos ( -Wl,rpath ... en la línea de comandos gcc). Las rutas definidas en esa variable se agregan a la entrada RPATH en su archivo binario ELF. (Puede ver que RPATH utiliza objdump -x binary-filename en la mayoría de los casos, no está allí. Aparece en mis binarios de desarrollo, pero una vez que se instala la versión final, se elimina el RPATH ).

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

LD_RUN_PATH realmente no representa una amenaza para la seguridad a menos que usted sea un programador y no sepa cómo usarlo. Como estoy usando CMake para compilar mi software, la -rpath se usa todo el tiempo. De esa manera no tengo que instalar todo para ejecutar mi software. ldd puede encontrar todos los archivos .so automáticamente. (Se suponía que el entorno automake debía hacer eso también, pero en comparación no era muy bueno).

LD_LIBRARY_PATH es una variable de tiempo de ejecución y, por lo tanto, debes 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 es una amenaza de seguridad, probablemente no. Si un hacker se apodera de su computadora, LD_LIBRARY_PATH es accesible para ese hacker de todos modos. Lo que podría suceder es que utilice las rutas incorrectas en esa variable, es posible que su binario no se cargue, pero si se carga, puede terminar con un binario que falla o al menos un binario que no funciona bien. Una de las preocupaciones es que con el tiempo obtiene nuevas versiones de la biblioteca y es probable que se olvide de eliminar LD_LIBRARY_PATH que significa que puede estar usando una versión no segura de la biblioteca.

La otra posibilidad de seguridad es si el pirata informático instala una biblioteca falsa con el mismo nombre que lo que el binario está buscando, una biblioteca que incluye todas las mismas funciones, pero que tiene algunas de esas funciones reemplazadas con código astuto. Puede obtener esa biblioteca cargada cambiando la variable LD_LIBRARY_PATH . Entonces eventualmente será ejecutado por el hacker. Nuevamente, si el pirata informático puede agregar una biblioteca de este tipo a su sistema, ya está dentro y es probable que no tenga que hacer nada de eso en primer lugar (ya que está dentro, tiene el control total de su sistema de todos modos). Porque en realidad, si el pirata informático solo puede colocar la biblioteca en su cuenta, no hará nada demasiado (a menos que su caja de Unix no sea segura en general ...) Si el pirata informático puede reemplazar una de sus bibliotecas /usr/lib/... , ya Tiene acceso completo a su sistema. Así que LD_LIBRARY_PATH no es necesario.

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 al 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

Puedes intentar agregar:

-Wl,-rpath,path/to/lib

a las opciones del enlazador. Esto le ahorrará la necesidad de preocuparse por la LD_LIBRARY_PATH entorno LD_LIBRARY_PATH , y puede decidir en el momento de la compilación apuntar a una biblioteca específica.

Para una ruta relativa al binario, puede usar $ ORIGIN, por ejemplo

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

(Es posible que $ ORIGIN no funcione al enlazar estáticamente a bibliotecas compartidas con ld, use -Wl, - allow-shlib-undefined para solucionar este problema)

Answer 4

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

Para citar tu primer enlace:

¿Cuándo debo configurar 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 solucionar.

Eso NO es lo que yo llamo una declaración de problema definitiva. De hecho me recuerda que no me gusta . [YouTube, pero SFW].

La segunda entrada del blog ( http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the ) está mucho más próxima sobre la naturaleza del problema ... que parece ser, en pocas palabras, los choques de la versión de la biblioteca. Este programa requiere Foo1. 2, pero ThatProgram requiere Foo1.3, por lo tanto, no puede ejecutar ambos programas (fácilmente). Tenga en cuenta que la mayoría de estos problemas se anulan mediante una simple secuencia de comandos de envoltura que establece LD_LIBRARY_PATH solo para el shell de ejecución, que es (casi siempre) un proceso secundario separado del shell interactivo.

Tenga en cuenta también que las alternativas están bastante bien explicadas en el post.

Estoy confundido en cuanto a por qué publicaría una pregunta con enlaces a artículos que aparentemente responden a su pregunta ... ¿Tiene alguna pregunta específica que no se haya cubierto (con suficiente claridad) en ninguno de esos artículos?