So löschen Sie eine Systemdatei als Administrator

Ich bin ein "admin"-Benutzer auf einem Mac, auf dem Big Sur läuft. Ich versuche, einen Symlink zu entfernen:

$ ls -al /usr/bin/python
lrwxr-xr-x  1 root  wheel  75 Jan  1  2020 /usr/bin/python -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7

Jetzt habe ich versucht, es mit zu entfernen, sudoaber ich bekomme die Erlaubnis verweigert:

$ sudo rm /usr/bin/python
rm: /usr/bin/python: Operation not permitted

Wie übernehme ich die tatsächliche Administratorbefugnis auf meinem Mac? Muss ich der Gruppe „Rad“ hinzugefügt werden?

Bitte beachten Sie, dass mir die hier beschriebenen Problemumgehungen mit Shell-Aliassen bekannt sind:

Upgrade auf Python 3.6 von Python 2.7 nicht möglich

Aber das wäre nur eine Umgehung. Ich möchte wissen, was die Ursache ist und was ich dagegen tun kann.

Auf Big Sur geht das nicht. Alle Systemdateien befinden sich auf einer schreibgeschützten Festplatte. Auch das Entfernen dieses Python wird einige Systemprogramme beschädigen, die benötigt werden, zB xattr
Wow. Haben Sie eine gute Quelle dafür, wie Big Sur Systemaktualisierungen und dergleichen verwaltet?
Sie sollten nichts dagegen tun. Unter macOS ist es normal, V3.x Python mit dem Befehl auszuführen python3. Der Befehl pythonsollte der eingebaute V2.x bleiben.
Willkommen bei Ask Different. Warum installieren Sie Ihre Tools nicht an den vom Benutzer modifizierbaren Orten? Das scheint ein XY-Problem zu sein.

Antworten (3)

Die Hauptursache hier ist, dass das Verzeichnis /usr/bin durch SIP (System Integrity Protection) geschützt ist. Daher kann niemand, nicht einmal Admin-Benutzer, den Inhalt des Verzeichnisses ändern, während SIP aktiv ist.

Die Systemordner auf Big Sur sind tatsächlich in einem separaten, kryptografisch signierten Dateisystem (Systemvolume) enthalten, das beim Booten schreibgeschützt gemountet wird. Sein Inhalt wird durch die Verwendung sogenannter Firmlinks in Ihr normales gemountetes Dateisystem mit Lese- und Schreibzugriff gemischt. Das bedeutet, dass es aussieht und sich anfühlt wie früher auf älteren macOS-Versionen – alles ist sozusagen an der richtigen Stelle – aber tatsächlich können die Systemdateien während des normalen Systembetriebs nicht geändert werden.

Theoretisch könnten Sie SIP deaktivieren, das Systemvolume als beschreibbar bereitstellen, den Python-Link ändern und das Ganze neu signieren. Ich würde jedoch dringend davon abraten, da Sie riskieren würden, von Apple bereitgestellte Tools zu beschädigen, die von der jeweiligen Python-Version abhängen - und Sie müssten wahrscheinlich einen endlosen Kampf führen, bei dem der Link während macOS-Upgrades wiederhergestellt wird.

Stattdessen würde ich Ihnen raten, entweder einen anderen Namen für das Programm zu verwenden (dh zum Beispiel python3 statt python) - oder einen Alias ​​in Ihrer Shell zu verwenden, damit "python" wirklich ein anders benanntes Programm ausführt.

Ich bevorzuge gefährliche Freiheit, aber jedem das seine
Ich weiß nicht, ob ich das genau Freiheit nennen würde - aber Sie sind natürlich frei, mit Ihrem eigenen Computer zu tun, was Sie wollen (im Rahmen der Gesetze). Wenn das bedeutet, zentrale Sicherheitsfunktionen zu deaktivieren oder zusätzliche Aufgaben zu erstellen, die während Upgrades erledigt werden müssen, ist das vollkommen in Ordnung. Nehmen Sie sich einfach eine Minute Zeit, um das Risiko und die damit verbundene Arbeit zu verstehen, bevor Sie beginnen – und denken Sie daran, Sicherungskopien anzulegen! :-)
@Lucky Das Ersetzen der Systemversion von Python kann Systemskripte beschädigen, die für Python 2 und nicht für Python 3 geschrieben wurden. Es ist viel sicherer, Ihre bevorzugte Version von Python woanders zu installieren (z. B. /usr/local/bin/), und stellen Sie sicher, dass dies der Fall ist vor /usr/bin in Ihrem PATH(was es standardmäßig ist).
Es ist seit mehr als 30 Jahren übliche Unix-Praxis, dass Sie, wenn Sie eine andere Version eines Systemprogramms haben möchten, es irgendwo nicht unter /usr außer /usr/local ablegen und PATH und/oder Aliase ändern. /usr gehört dem Hersteller zB Sun HP Next DEC etc
Welche Version von Python und von wo aus installieren Sie, ob das System Python vorhanden ist oder nicht? Downloads von python.org, MacPorts, sogar Homebrew kümmern sich nicht darum.
@mmmmmm das verstehe ich total. Ich war eher neugierig, was vis a vis SIP los war.
Die Hauptursache ist das schreibgeschützte versiegelte Systemvolumen (Antwort Absatz 2), das Änderungen verbietet. SIP schützt nicht /usr/bin/python.
> "Ich würde Ihnen raten, entweder einen anderen Namen für das Programm zu verwenden (dh zum Beispiel python3 statt python) - oder einen Alias ​​in Ihrer Shell zu verwenden, damit "python" wirklich ein anders benanntes Programm ausführt." Dies sind nicht die einzigen Optionen. In vielerlei Hinsicht besteht die beste Lösung darin, your so einzustellen, dass es die ausführbare Datei Ihrer Wahl PATHfindet , bevor es . (Wie @Gordon auch empfiehlt) python/usr/bin/python
Ich habe nie gesagt, dass dies die einzigen Optionen sind ... das Ändern von PATH ist natürlich auch eine Möglichkeit, aber Sie riskieren, Dinge zu beschädigen, die darauf angewiesen sind, dass der Standard-Python derjenige im Pfad ist. Wenn Sie wissen, welche Art von Software Sie installiert haben, ist das Risiko jedoch wahrscheinlich sehr gering.

Lesen Sie die Kommentare, die Antwort auf die größere, nicht explizit gestellte Frage „Was hat Apple getan, um das Betriebssystem zu sichern und Entwicklern zu ermöglichen, Versionen von Befehlszeilentools zu überlagern, um ihre Arbeit zu erledigen?“

Wenn Sie diese Frage haben: Das beste Schreiben in der Entwicklung der kommandozeilenrelevanten Änderungen von Mojave über Catalina bis Big Sur ist hier:

Das erste halbe Dutzend Absätze legt klar dar, was los ist, und wird jedem, der ein modernes macOS-System anpassen möchte, sehr helfen.

Das signierte und schreibgeschützte Systemvolumen wird viele alte Anleitungen und Antworten zerstören, da einige traditionelle Unix-Annahmen nicht mehr gültig sind (wie die Notwendigkeit, root zu sein oder was ein Administrator tun könnte, um Systemdateien im Allgemeinen zu ändern).

Ich würde nicht sagen, dass "traditionelle Unix-Annahmen nicht mehr gültig sind" als solche. Dass /usr schreibgeschützt ist, ist eigentlich so, wie es früher auf den meisten Unix-Systemen war. Die FHS erlaubt das heute noch, und einige tun das auch auf typischen "Nicht-so-Unix-ähnlichen-Unix-Systemen" wie Linux.
Sie würden nicht zustimmen, dass einige Annahmen nicht mehr gültig sind? @jksoegaard
Hier ging es speziell darum, /usr nicht ändern zu können, da es schreibgeschützt ist. Wenn Sie an ältere macOS-Versionen gewöhnt sind, dann ja, das würde Ihre Annahmen brechen. Wenn Sie jedoch nur "traditionelle Unix-Annahmen" haben, wären Sie überhaupt nicht überrascht, dass /usr schreibgeschützt ist.
Ich bin nicht einverstanden. Als ich anfing, Unix auf dem Desktop zu verwenden, sudo rm /usr/bin/whateverhätte es trotz Nur-Lese-Berechtigungen auf dem Dateisystem funktioniert. Aber das war, bevor Python erfunden wurde, also stimmt unsere Definition von traditionellem Unix vielleicht nicht?
Nur-Lese-Berechtigungen für eine Datei und ein schreibgeschützt gemountetes Dateisystem sind zwei sehr unterschiedliche Dinge. /usr auf verschiedenen Unixen schreibgeschützt gemountet zu werden, war ziemlich üblich. Vielleicht erinnern Sie sich aufgrund der Zeit, die vergangen ist, an etwas anderes? - Ich nehme an, Sie meinten, dass Sie Mitte der 80er Jahre Unix auf dem Desktop verwendet haben. Meine Erfahrungen mit Unix (hauptsächlich Servern) begannen etwas später in den frühen 90er Jahren, und ich erinnere mich deutlich, dass /usr auf HP-UX- und AIX-Rechnern schreibgeschützt gemountet wurde. Ich erinnere mich auch, dass es ziemlich üblich war, dass wir Solaris-Workstations mit /usr-montierten schreibgeschützten [...]
[...] über NFS.
Großartig - wir haben BSD auf IBM RT/RS- und DEC-Workstations ausgeführt. X11 für den Sieg! Wir haben die gleiche Ausrichtung, denke ich.

Sie können Folgendes ausgeben:

csrutil disable

Befehl zum Deaktivieren des Systemintegritätsmodus (SIM).

dann, während im Wiederherstellungsmodus noch:

sudo rm -rf /target

Das Deaktivieren der SIM-Karte ist im Allgemeinen verpönt, und ich empfehle, sich darüber zu informieren, bevor Sie diese Strategie weiterverfolgen. Ich habe mich dafür entschieden und bin mit dem Ergebnis zufrieden.

So löschen Sie eine Systemdatei als Administrator
AntwortenHierDatenschutz-Bestimmungen1y, 0v