Impossibile impostare DYLD_FALLBACK_LIBRARY_PATH nella shell su OSX 10.11.1

Negli script di shell utilizzati per i test di unità con librerie dinamiche in una directory diversa dal tipico @rpath, in precedenza sono stato in grado di impostare DYLD_FALLBACK_LIBRARY_PATH per impostare la directory contenente le librerie. In 10.11.1, bash sembra ignorare i tentativi di impostare questa variabile d'ambiente:

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

e DYLD_FALLBACK_LIBRARY_PATH non è presente nell'output di printenv.

È un hack relativo alla sicurezza nella shell di 10.11? Non sono stato in grado di trovare questa modifica documentata nelle pagine man o online.

— Tipo
fonte

Install_name_tool sarebbe d' aiuto?

— Saaru Lindestøkke,

Certo, install_name_tool è una soluzione permanente (e l'ho effettivamente copiato per configurare l'ambiente di compilazione). Per i test rapidi e il debug in un ambiente di sviluppo, è una seccatura dover fare copie temporanee delle librerie, hackerare le modifiche di @rpath e quindi eventualmente dimenticare le modifiche manuali. DYLD_FALLBACK_LIBRARY_PATH e DYLD_LIBRARY_PATH sono stati utili per questi cicli di sviluppo / test occasionali.

— Guy

Questa è la protezione dell'integrità del sistema introdotta in El Capitan

La documentazione è in questo da Apple

Fondamentalmente qualsiasi eseguibile OS X fornito da Apple è protetto. e (da un documento precedente)

La generazione di processi figlio di processi limitati da System Integrity Protection, come l'avvio di un processo di supporto in un bundle con NSTask o la chiamata al comando exec (2), ripristina le porte speciali Mach di quel processo figlio. Qualsiasi variabile di ambiente Dynamic Linker (dyld), come DYLD_LIBRARY_PATH, viene eliminata all'avvio di processi protetti.

In questo caso sh è protetto

— user151019
fonte

Grazie per il puntatore! Mi ero concentrato sul kernel e su altre protezioni del filesystem in SIP. Non ho notato questo cambiamento.

— Guy,

Ok, questo spiega l'origine del fenomeno, ma come diamine dovremmo ora testare le librerie non installate? Voglio dire, come possiamo scrivere make checksu El Capitan quando sono necessarie librerie condivise?

— circa

La maggior parte di make via autoconf dovrebbe finire in / usr / local che è ancora scrivibile - se provano in qualsiasi altro posto sotto / usr

— metterei in

Se qualcuno lo trova dopo aver perso tempo a cercare di capire perché i variegati ambienti dyld stavano scomparendo, prendi in considerazione la possibilità di presentare un bug ad Apple per far loro documentare l'interazione dyld / SIP. L'ho già fatto e il bug ha ottenuto il numero rdar: // 30755019. (Spero che poi penseranno di documentare altre simili trappole ...)

— Hmijail piange le dimissioni il

(Intendevo documentare l'interazione SIP nella manpage dyld, che al momento della stesura è totalmente mamma a riguardo)

— hmijail piange le dimissioni il