DYLD_FALLBACK_LIBRARY_PATH kann in der Shell unter OSX 10.11.1 nicht festgelegt werden

In Shell-Skripten, die für Komponententests 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 zu setzen:

$ 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 finden.

Würde das install_name_tool helfen?
Sicher, install_name_tool ist eine dauerhafte Lösung (und ich habe tatsächlich ein Skript erstellt, um die Build-Umgebung einzurichten). Zum schnellen Testen und Debuggen in einer Entwicklungsumgebung ist es mühsam, temporäre Kopien von Bibliotheken zu erstellen, @rpath-Änderungen einzuhacken und dann möglicherweise die manuelle Änderung zu vergessen. DYLD_FALLBACK_LIBRARY_PATH und DYLD_LIBRARY_PATH waren praktisch für diese gelegentlichen Entwicklungs-/Testzyklen.

Antworten (1)

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

Dokumentation ist dabei von Apple

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

Das Spawnen von untergeordneten Prozessen von Prozessen, die durch den Systemintegritätsschutz eingeschränkt sind, z. B. durch Starten eines Hilfsprozesses in einem Bündel mit NSTask oder Aufrufen des exec(2)-Befehls, setzt die Mach-Spezialports dieses untergeordneten Prozesses zurück. Alle Umgebungsvariablen für dynamische Linker (dyld), wie z. B. DYLD_LIBRARY_PATH, werden gelöscht, wenn geschützte Prozesse gestartet werden.

In diesem Fall ist sh geschützt

Danke für den Hinweis! Ich hatte mich auf den Kernel und andere Dateisystemschutzmaßnahmen in SIP konzentriert. Habe diese Änderung nicht bemerkt.
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 Shared Libs benötigt werden?
Die meisten make via autoconf sollten in /usr/local landen, das immer noch beschreibbar ist - wenn sie es irgendwo anders unter /usr versuchen, würde ich die Kenntnisse 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, erwägen Sie, einen Fehler bei Apple einzureichen, damit sie die dyld/SIP-Interaktion dokumentieren. Das habe ich bereits getan, und der Fehler hat die Nummer rdar://30755019. (Ich hoffe, dass sie dann daran denken, weitere solche Fallen zu dokumentieren ...)
(Ich meinte, die SIP-Interaktion in der dyld-Manpage zu dokumentieren, die zum jetzigen Zeitpunkt völlig unklar ist.)
@Markieren Sie, dass der Link des PDFs defekt ist. Erinnern Sie sich an den Titel?
DYLD_FALLBACK_LIBRARY_PATH kann in der Shell unter OSX 10.11.1 nicht festgelegt werden
AntwortenHierDatenschutz-Bestimmungen1y, 0v