DYLD_FALLBACK_LIBRARY_PATH kann in der Shell unter OSX 10.11.1 nicht festgelegt werden

In Shell-Skripten, die zum Testen von Einheiten mit dynamischen Bibliotheken in einem anderen Verzeichnis als dem typischen @rpath verwendet werden, konnte ich zuvor DYLD_FALLBACK_LIBRARY_PATH festlegen, um das Verzeichnis festzulegen, das die Bibliotheken enthält. Unter 10.11.1 scheint bash Versuche zu ignorieren, diese Umgebungsvariable festzulegen:

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

und DYLD_FALLBACK_LIBRARY_PATH ist in der Ausgabe von printenv nicht vorhanden.

Ist dies ein sicherheitsrelevanter Hack in der Shell von 10.11? Ich konnte diese Änderung nicht in Manpages oder online dokumentieren.

— Kerl
quelle

Würde das install_name_tool helfen?

— Saaru Lindestøkke

Sicher, install_name_tool ist eine permanente Lösung (und ich habe sie tatsächlich per Skript erstellt, um die Build-Umgebung einzurichten). Für schnelles Testen und Debuggen in einer Entwicklungsumgebung ist es mühsam, temporäre Kopien von Bibliotheken zu erstellen, @ rpath-Änderungen zu hacken und dann möglicherweise die manuelle Änderung zu vergessen. DYLD_FALLBACK_LIBRARY_PATH und DYLD_LIBRARY_PATH waren für diese gelegentlichen Entwicklungs- / Testzyklen praktisch.

— Guy

Dies ist der in El Capitan eingeführte Systemintegritätsschutz

Die Dokumentation ist in dieser von Apple

Grundsätzlich sind alle von Apple bereitgestellten ausführbaren OS X-Dateien geschützt. und (aus einem früheren Dokument)

Durch das Laichen von untergeordneten Prozessen von Prozessen, die durch den Systemintegritätsschutz eingeschränkt sind, z. B. durch Starten eines Hilfsprozesses in einem Bundle mit NSTask oder Aufrufen des Befehls exec (2), werden die Mach-Spezialports dieses untergeordneten Prozesses zurückgesetzt. Alle Umgebungsvariablen für dynamische Linker (dyld), z. B. DYLD_LIBRARY_PATH, werden beim Starten geschützter Prozesse gelöscht.

In diesem Fall ist sh geschützt

— user151019
quelle

Danke für den Zeiger! Ich hatte mich auf den Kernel und andere Dateisystemschutzfunktionen in SIP konzentriert. Ich habe diese Änderung nicht bemerkt.

— Guy

Ok, das erklärt den Ursprung des Phänomens, aber wie zum Teufel sollen wir jetzt nicht installierte Bibliotheken testen? Ich meine, wie können wir make checkauf El Capitan schreiben, wenn gemeinsame Bibliotheken benötigt werden?

— Akim

Die meisten make via autoconf sollten in / usr / local landen, was noch beschreibbar ist - wenn sie irgendwo anders unter / usr versuchen, würde ich das Wissen des Autors über OS X (oder Unix) in

— Frage stellen

Wenn jemand dies findet, nachdem er Zeit damit verschwendet hat, zu verstehen, warum die Dyld-Umgebungsvariablen verschwunden sind, sollten Sie einen Fehler bei Apple einreichen, damit er die Dyld / SIP-Interaktion dokumentiert. Ich habe es bereits getan und der Fehler hat die Nummer rdar: // 30755019. (Ich hoffe, dass sie dann darüber nachdenken werden, andere solche Fallen zu dokumentieren ...)

— hmijail trauert um Rücktritte

(Ich wollte die SIP-Interaktion in der Dyld-Manpage dokumentieren, die zum

— jetzigen Zeitpunkt