No se puede configurar DYLD_FALLBACK_LIBRARY_PATH en shell en OSX 10.11.1

En los scripts de shell utilizados para pruebas unitarias con bibliotecas dinámicas en un directorio que no sea el típico @rpath, anteriormente pude configurar DYLD_FALLBACK_LIBRARY_PATH para configurar el directorio que contiene las bibliotecas. En 10.11.1, bash parece ignorar los intentos de establecer esta variable de entorno:

$ sh -x testscript.sh
+ DYLD_FALLBACK_LIBRARY_PATH=/Users/something/testinglibs
+ export DYLD_FALLBACK_LIBRARY_PATH
+ exec printenv

y DYLD_FALLBACK_LIBRARY_PATH no está presente en la salida de printenv.

¿Es este un truco relacionado con la seguridad en el shell de 10.11? No he podido encontrar este cambio documentado en las páginas man o en línea.

Claro, install_name_tool es una solución permanente (y de hecho la he creado para configurar el entorno de compilación). Para pruebas y depuración rápidas en un entorno de desarrollo, es una molestia tener que hacer copias temporales de las bibliotecas, hackear los cambios de @rpath y luego, posiblemente, olvidarse del cambio manual. DYLD_FALLBACK_LIBRARY_PATH y DYLD_LIBRARY_PATH fueron útiles para estos ciclos ocasionales de desarrollo/prueba.

Respuestas (1)

Esta es la Protección de integridad del sistema introducida en El Capitan

La documentación está en esto de Apple

Básicamente, todos los ejecutables de OS X proporcionados por Apple están protegidos. y (de un documento anterior)

Generar procesos secundarios de procesos restringidos por System Integrity Protection, como iniciar un proceso auxiliar en un paquete con NSTask o llamar al comando exec(2), restablece los puertos especiales de Mach de ese proceso secundario. Todas las variables de entorno del vinculador dinámico (dyld), como DYLD_LIBRARY_PATH, se eliminan al iniciar procesos protegidos.

En este caso sh está protegido

¡Gracias por la anotación! Me había centrado en el kernel y otras protecciones del sistema de archivos en SIP. No noté este cambio.
Ok, esto explica el origen del fenómeno, pero ¿cómo diablos se supone que vamos a probar bibliotecas no instaladas? Quiero decir, ¿cómo podemos escribir make checken El Capitán cuando se necesitan bibliotecas compartidas?
La mayoría de las creaciones a través de autoconf deberían terminar en /usr/local, que aún se puede escribir; si intentan en cualquier otro lugar bajo /usr, cuestionaría el conocimiento del autor de OS X (o Unix)
Si alguien encuentra esto después de perder el tiempo tratando de entender por qué las variables del entorno dyld estaban desapareciendo, considere presentar un error con Apple para que documenten la interacción dyld/SIP. Ya lo hice, y el error obtuvo el número rdar://30755019. (Espero que luego piensen en documentar otras trampas similares...)
(Me refiero a documentar la interacción SIP en la página de manual de dyld, que a partir de este escrito es totalmente silencioso al respecto)
@Marque el enlace del pdf está roto... ¿recuerda su título?
No se puede configurar DYLD_FALLBACK_LIBRARY_PATH en shell en OSX 10.11.1
RespuestasAquíPolítica de privacidad1y, 0v