Nie można ustawić DYLD_FALLBACK_LIBRARY_PATH w powłoce na OSX 10.11.1


10

W skryptach powłoki używanych do testowania jednostek z dynamicznymi bibliotekami w katalogu innym niż typowy @rpath, wcześniej byłem w stanie ustawić DYLD_FALLBACK_LIBRARY_PATH, aby ustawić katalog zawierający biblioteki. Pod 10.11.1 bash wydaje się ignorować próby ustawienia tej zmiennej środowiskowej:

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

a DYLD_FALLBACK_LIBRARY_PATH nie występuje w wydruku printenv.

Czy to hack związany z bezpieczeństwem w powłoce 10.11? Nie udało mi się znaleźć tej zmiany udokumentowanej na stronach man lub online.



Pewnie, nazwa_instalacji_tool jest rozwiązaniem trwałym (i faktycznie napisałem skrypt, aby skonfigurować środowisko kompilacji). W celu szybkiego testowania i debugowania w środowisku programistycznym, kłopotliwe jest tworzenie tymczasowych kopii bibliotek, hackowanie zmian @rpath, a następnie prawdopodobnie zapomnienie o ręcznej zmianie. DYLD_FALLBACK_LIBRARY_PATH i DYLD_LIBRARY_PATH były przydatne do tych sporadycznych cykli dev / test.
— Guy

Odpowiedzi:


8

Jest to ochrona integralności systemu wprowadzona w El Capitan

Dokumentacja jest w to od Apple

Zasadniczo wszystkie pliki wykonywalne Apple OS X są chronione. i (z wcześniejszego dokumentu)

Odradzanie procesów dziecięcych procesów ograniczonych przez ochronę integralności systemu, takich jak uruchomienie procesu pomocniczego w pakiecie z NSTask lub wywołanie komendy exec (2), resetuje specjalne porty Mach tego procesu potomnego. Wszelkie dynamiczne zmienne środowiskowe linkera (dyld), takie jak DYLD_LIBRARY_PATH, są czyszczone podczas uruchamiania chronionych procesów.

W tym przypadku sh jest chroniony


Dzięki za wskaźnik! Skupiłem się na ochronie jądra i innych systemów plików w SIP. Nie zauważyłem tej zmiany.
— Guy

2
Ok, to wyjaśnia pochodzenie tego zjawiska, ale jak do cholery mamy teraz testować nie zainstalowane biblioteki? Mam na myśli, jak możemy pisać make check na El Capitan, kiedy potrzebne są współdzielone biblioteki?
— akim

Większość make via autoconf powinna znaleźć się w katalogu / usr / local, który jest nadal zapisywalny - jeśli spróbują gdziekolwiek indziej w katalogu / usr, będę kwestionować wiedzę autora na temat OS X (lub Unix)
— Mark

Jeśli ktokolwiek znajdzie to po marnowaniu czasu na próbę zrozumienia, dlaczego zniknęły zmienne środowiska VAR, rozważ zgłoszenie błędu w Apple, aby udokumentować interakcję dyld / SIP. Zrobiłem już, a błąd otrzymał numer rdar: // 30755019. (Mam nadzieję, że pomyślą o udokumentowaniu innych takich pułapek ...)
— hmijail

1
(Miałem na myśli dokument interakcji SIP w podręczniku dyld, który w chwili pisania tego jest całkowicie mamą o tym)
— hmijail
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.