Sind meine Berechtigungen für /usr/local/ korrekt?

Ich verwende HomeBrew für meine Portanforderungen (scheint etwas „sauberer“ als MacPorts zu sein).

Ich kann ohne sudoing installieren (was großartig ist), aber der Man-Linking-Schritt scheint dies zu erfordern ( /usr/local/share/man/man3im Besitz von root).
Eine Anleitung, die ich gefunden habe, schlägt vor, dass ich rekursiv chown /usr/localtue

sudo chown -R `whoami` /usr/local

Ist das sicher … oder ist es eine schlechte Idee™?

Außerdem: Sind meine Berechtigungen korrekt?

$ pwd
/usr/local/share/man
$ ls -lah
total 32
drwxrwxr-x    8 root  staff   272B  4 Set 11:02 .
drwxrwxr-x    9 root  staff   306B 10 Set 11:27 ..
drwxr-xr-x    3 root  wheel   102B  4 Ago  2009 de
drwxrwxr-x  163 root  staff   5,4K 10 Set 11:27 man1
drwxr-xr-x   11 root  wheel   374B 10 Set 11:27 man3
drwxr-xr-x    7 ago   staff   238B 10 Set 11:39 man5
drwxr-xr-x   11 ago   staff   374B 10 Set 11:39 man7
-rw-r--r--    1 root  staff    13K  4 Set 11:02 whatis
So soll Homebrew verwendet werden. Einige Leute mögen anderer Meinung sein, aber der leitende Entwickler sagt, dass man es so machen soll.
Etwas bessere Alternative zu Ihrem Chown: sudo chown -R :admin /usr/local. Auf diese Weise funktioniert es für jeden Administratorbenutzer des Computers gleich. Möglicherweise müssen Sie jedoch auch ausführen sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+, um sicherzustellen, dass die Gruppe denselben Schreibzugriff wie der Benutzer hat.
„Ich werde Homebrew verwenden, es fühlt sich sauberer an als Macports. Oh, sehen Sie sich dieses schlecht definierte Berechtigungs-Chaos an. Ich werde Stack Overflow überprüfen. Oh, hier ist ein schneller Hack, der gegen die Best Practices von Unix und gegen das, was Betriebssystem-Updates versuchen, verstößt durchzusetzen. Perfekt!". Monat später: „Hey, wie wurde diese Malware installiert?“
Das Problem, das ich bei diesem Ansatz habe, ist, dass nur das Benutzerkonto, das Homebrew installiert, es verwenden kann. Ich habe einen Mac mit mehreren Konten, die ich verwende, um Arbeitsprojekte von Heimprojekten zu trennen (zum Beispiel). Wenn ich im falschen Konto angemeldet bin, kann ich Brew Install nicht verwenden. Ich habe diesen Weg eingeschlagen, um die Gefahren der Verwendung von root zu vermeiden, aber ich bin nicht überzeugt, dass dies der beste Ansatz ist.
@MikeMcQuaid Ich finde es interessant, dass Homebrew endlich einen Fehler zugegeben und in der neuen Version, die vor ein oder zwei Wochen veröffentlicht wurde, die Standardberechtigungen für /usr/local wiederhergestellt hat
@Agos Siehe Kommentar oben

Antworten (7)

Es ist normalerweise besser, die Berechtigungen so streng wie möglich zu halten. Besitz behalten /usr/localdurch rootbedeutet, dass nur Prozesse, die als root/ ausgeführt werden sudo(oder über das Apple-Autorisierungsdialogfeld nach einem Admin-Benutzer fragen), in diesen Bereich schreiben können. Daher muss ein Prozess-Download Sie nach einem Passwort fragen, bevor dort Dateien beschädigt werden.

Aber wie Sie sagen, macht es das Hinzufügen neuer Programme schwieriger.

Ich bin mit running einverstanden sudo, da Sie Dinge seltener installieren als ausführen, aber Sie müssen darauf vertrauen, dass der Build-Prozess nichts ändert, was er sollte.

Wenn Sie sudo vermeiden möchten, würde ich Homebrew installieren ~/usr/localund Ihren Pfad, Manpath usw. ändern, um die Verzeichnisse darunter einzuschließen.

Eine bessere Möglichkeit besteht darin, einen anderen Benutzer anzulegen – sagen wir, homebrewund ein Verzeichnis zu erstellen, das diesem Benutzer gehört. Installieren Sie dann dort mit sudo -U homebrew. Andere Benutzer haben den Vorteil, dass sie keine anderen Dateien überschreiben können, da sie nicht ausgeführt werden rootund andere Programme Homebrew nicht beeinflussen können. (Ich stelle fest, dass die Homebrew-FAQ diesen neuen Benutzer vorschlägt, wenn Sie sich in einer "Mehrbenutzerumgebung" befinden. Ich würde sagen, dass jede Unix-Maschine, einschließlich macOS, eine Mehrbenutzerumgebung ist.)

Wie das Homebrew-Wiki jedoch sagt, finden die Rezepte nicht alle Fälle von /usr/localund ersetzen sie durch das ausgewählte Verzeichnis, von dem ich vermute, dass wir bei stecken bleiben /usr/local.

+1, um Autorisierungen streng zu halten und Benutzerverzeichnisse zu ändern $PATHund einzuschließen. $MANPATHWenn die installierten Programme keine systemweite Installation erfordern, ist dies eine viel bessere Alternative.
+1 und akzeptierte Antwort für „Berechtigungen so streng wie möglich halten“. Doing brew doctor(unten vorgeschlagen) sagte mir, dass ich nur die Shared Man-Verzeichnisse chownen muss ... sicher genug für mich.
Eine Kompromisslösung, zumindest für Leute, denen die Sicherheit wichtig genug ist, um nicht ständig als Admin-Benutzer zu arbeiten, besteht darin, den Gruppenbesitz und die Berechtigungen zu ändern, sodass nur Admins in /usr/local schreiben können. Siehe kenorbs Antwort.
@Mark Ich finde es interessant, dass Homebrew dies endlich bemängelt hat und in der neuen Version, die vor ein oder zwei Wochen veröffentlicht wurde, die Standardberechtigungen für /usr/local wiederhergestellt hat

Ich benutze auch Homebrew und kann bestätigen, dass es absolut sicher ist. Zitieren der Installationsseite auf der offiziellen Homebrew-FAQ :

Tun Sie sich selbst einen Gefallen und wählen Sie aus/usr/local

  1. Es ist einfacher
    /usr/local/bin ist bereits in Ihrer PATH.

  2. Es ist einfacher
    Tonnen von Build-Skripten brechen, wenn ihre Abhängigkeiten weder in /usr noch in /usr/local sind. Wir beheben dies für Homebrew-Formeln (obwohl wir nicht immer darauf testen), aber Sie werden feststellen, dass viele RubyGems- und Python-Setup-Skripte kaputt gehen, was außerhalb unserer Kontrolle liegt.

  3. Es ist sicher,
    dass Apple sich an POSIX angepasst und dieses Verzeichnis für uns hinterlassen hat. Das bedeutet, dass /usr/localstandardmäßig kein Verzeichnis vorhanden ist, sodass Sie sich keine Sorgen machen müssen, vorhandene Tools durcheinander zu bringen.

Wenn Sie vorhaben, Juwelen zu installieren, die von Gebräuen abhängen, sparen Sie sich eine Menge Ärger und installieren Sie auf /usr/local!

Es ist nicht trivial, gem anzuweisen, in nicht standardmäßigen Verzeichnissen nach Headern und Dylibs zu suchen. Wenn Sie sich entscheiden /usr/local, „geht einfach alles!“

Ich möchte nur hinzufügen, dass es eine sehr schlechte Idee ist, Dinge als root zu tun , daher erscheint mir chowning /usr/localnicht nur vernünftig (es ist kein Systemverzeichnis unter OSX), sondern vernünftig .

Ihre Berechtigungen sind (noch) nicht korrekt. Führen Sie einfach den von Ihnen aufgelisteten Befehl aus, und alles wird gut.

Wenn Sie andere Probleme haben, denken Sie daran, die brew doctorkönnen Ihnen helfen!

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
Der Chat ist weg, was schade ist. Auf die Gefahr hin, die Geschichte zu wiederholen, werde ich hier meinen Kommentar hinterlassen: Dass dies getan wird, bedeutet nicht, dass dies sicher ist.
Der Kern des Diagramms ist, obwohl Homebrew dies vorschlägt, gibt es Gründe dafür, warum dies falsch ist
brew doctorist einfach genial.
@Carmine Paolino Ich finde es interessant, dass Homebrew dies endlich bemängelt hat und in der neuen Version, die vor ein oder zwei Wochen veröffentlicht wurde, die Standardberechtigungen für /usr/local wiederhergestellt hat

adminWenn Sie Homebrew verwenden, sollten Sie einer bestimmten Gruppe (entweder oder ) die Schreibberechtigung erteilen staff, damit die Dateien von Benutzern dieser Gruppe gemeinsam genutzt werden können.

Zum Beispiel:

sudo chgrp -R admin /usr/local /Library/Caches/Homebrew
sudo chmod -R g+w /usr/local /Library/Caches/Homebrew

Weisen Sie dann die Benutzer, die Zugriff auf das brewKommando haben sollen, dieser Gruppe zu (überprüfen Sie Ihre Gruppen über: id -Gn).

Wenn Sie dann mit arbeiten brew, führen Sie es nicht mit aus sudo.

Wenn immer noch ein Berechtigungsproblem besteht, führen Sie es aus brew doctor, um das Problem zu beheben.

+1 für eine tatsächliche, besser erzogene Lösung, auch wenn sie noch nicht wirklich fertig ist. Zum Beispiel: einen Benutzer zur Admin-Gruppe auf BSD-Ebene hinzufügen? Wird das nicht das Konzept der Admin-Benutzer von OS X durcheinander bringen?
Fürs Protokoll, ich habe diese Anweisungen befolgt, aber nur meinen bestehenden, von der OS X-GUI erstellten Admin-Benutzer verwendet, anstatt irgendjemanden zu irgendeiner Gruppe in der CLI hinzuzufügen. Es funktioniert: Um Brühbefehle ausführen zu können, muss ich zuerst tun su myAdminUser, und dann funktioniert alles wie vorgesehen. Aber natürlich bietet diese Lösung keine Sicherheit für Leute, die sowieso schon ständig einen Admin-Benutzer haben.
Dies ist wahrscheinlich der beste Weg, da stimme ich @kenorb zu

Für das, was es wert ist, /usr/localwird OS X nicht als "System" -Ordner betrachtet, und bei einer brandneuen Snow Leopard-Installation ist dieser Ordner leer.

Jedes root-eigene Material in diesem Ordner ist das Ergebnis einer sudo make installanderen Software oder der Eingabe Ihres Passworts nach einem Doppelklick auf eine .pkg, die Daten in /usr/local.

Der Besitz /usr/localhat über ein Jahr lang auf 2 Maschinen "für mich funktioniert".

Ein Fallstrick ist, dass, wenn Sie MySQL installiert haben (ohne Homebrew) und seine Dateien zu chownen, es seine Datenbanken wahrscheinlich nicht mehr sehen kann (also müssten Sie sie zurück zu dem Benutzer chown, unter dem MySQL läuft .)

gcc und andere Entwicklungstools suchen automatisch in /usr/local, sodass das System davon betroffen ist
Das Problem ist nicht, dass es sich um einen „System“-Ordner handelt; Es ist, dass es sich um einen "systemweiten" Ordner handelt. Auch wenn nichts dort ist, /usr/local/binist es immer noch im Standardwert $PATH, und was auch immer Sie dort eingeben, kann auch von anderen Benutzern verwendet werden und sollte vertrauenswürdig sein . Wenn das gesamte /usr/local/Verzeichnis über die gleichen Berechtigungen verfügt , die /usr/local/share/manderzeit für das Setup von OP gelten, kann jeder gehen und jede Binärdatei mit einem Skript ändern, das dies tut rm -rf ~.
zu riskant: Wahrscheinlich werde ich früher oder später MySQL installieren
@Agos: Sie können MySQL immer mit HomeBrew installieren, in diesem Fall werden Sie keine Probleme haben :)
@CarminePaolino Keine gute Idee. Normalerweise benehmen sich Mac-Installer wie MySql besser als selbst ein sehr guter Paketmanager wie Homebrew.
@Agos Überhaupt nicht riskant. Die Vorsicht gilt nur, wenn Sie MySQL vor Homebrew installiert haben. Wenn Sie es danach tun, /usr/localsollten die Berechtigungen in Ordnung sein. (Aber Sie verwenden wahrscheinlich sowieso Postgres. :) )

Wie in Homebrew 1.0.0:

Homebrew muss nicht länger Eigentümer von /usr/local sein. Wenn Sie möchten, können Sie /usr/local auf seinen Standardbesitz zurücksetzen mit: sudo chown root:wheel /usr/local

Ich aktualisiere derzeit Brew mit brew update, was immer noch den Besitz von erfordert /usr/local. Ich werde versuchen, die Berechtigungen danach wiederherzustellen.
Das sind wirklich tolle Infos! Ich habe Perms wie von Homebrew (<1.0) angegeben eingestellt, und nach der Aktualisierung gab es diese Anweisungen zum Zurücksetzen.

Kann ab macOS High Sierra oder neuer /usr/localnicht mehr gechown werden.

Das Homebrew-Team empfiehlt nun : sudo chown -R $(whoami) $(brew --prefix)/*Homebrew-Berechtigungen zu reparieren.

Weitere Informationen dazu , warum Homebrew empfiehlt, die Homebrew-Verzeichnisse zu übernehmen, finden Sie in der Antwort von @Carmine Paolino .

Ich denke, es ist in Ordnung, wenn Benutzer Schreibrechte haben /usr/local– schließlich bedeutet das, dass Sie nicht sudojedes Build-Skript verwenden. Ich mag die Idee nicht, dass ein gewöhnlicher Benutzer /usr/local . Ich würde es vorziehen, root (oder ähnliches) zu besitzen /usr/local, aber die Berechtigungen so zu ändern, dass Benutzer (oder zumindest eine privilegierte Gruppe) darauf schreiben können. Das scheint der konzeptionell richtige Ansatz zu sein.

Das Problem hier ist, dass /usr/local/bines für die meisten Benutzer sehr wohl am Anfang von $PATH stehen kann. Das Verzeichnis weltweit beschreibbar zu machen, öffnet auf diese Weise viele Sicherheitslücken.
@patrix Also ändere die Pfade. :) Wenn Sie Skripte haben, die aufgrund mehrdeutiger Befehlspfade Sicherheitslücken aufweisen, würde ich den Skripten die Schuld geben, nicht Ihren Berechtigungen - Befehle, die in Skripten aufgerufen werden, sollten aus genau diesem Grund normalerweise vollständig qualifiziert sein. Wie auch immer, es gibt keine bessere Lösung: Entweder Sie geben Ihrem Administratorkonto eine unsichere umask, oder Sie führen alle Ihre Build-Skripte mit sudoaus, oder Sie geben einigen Benutzern Schreibrechte für /usr/local. Ich nehme den dritten als am wenigsten riskant ... es sei denn, Sie kennen einen besseren Weg.
Hmm. Wenn Sie noch etwas darüber nachdenken, wäre es vielleicht ein besserer Weg, Homebrew das tun zu lassen, was RVM standardmäßig tut: alles in ~/brewoder so installieren. Das Problem ist jedoch, dass im Gegensatz zu Ruby, das ziemlich eigenständig ist, viele *nix-Dienstprogramme erwarten, sich in /usr/local...
Ich habe vergessen zu erwähnen, dass meine /usr/localnicht weltweit beschreibbar ist: Vielmehr habe ich eine vertrauenswürdige Gruppe homebrew(nicht nur admin), die Schreibrechte darauf hat (erweiterte Berechtigungen wie 0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inherittotal rock). Dies ist der beste Kompromiss, den ich finden konnte: keine sudoOn-Build-Skripte, aber etwas Kontrolle über /usr/local.
@MarnenLaibow-Koser Ich würde gerne eine ausführlichere Erklärung dieses Ansatzes sehen (Erstellen einer vertrauenswürdigen Gruppe von Benutzern mit Schreibberechtigungen für /usr/local). Führen Sie eine Menge Schleppnetzsuche auf SO und anderen Websites durch und sehen Sie Argumente bezüglich: Verschieben von Homebrew in den Home-Ordner des Benutzers vs. Behalten in /usr/local, Ändern des Besitzers und/oder der Gruppe von /usr/localoder nicht und so weiter ... es ist schwer zu sagen, ob es welche gibt allgemein akzeptable Lösung. Haben Sie dazu einen Blogbeitrag oder Artikel oder könnten Sie irgendwo eine tiefere Erklärung geben?
@GabrielL. läuft darauf hinaus, ob Sie mehr als einen Benutzer haben (und auch meine Antwort), wenn ja, welcher Benutzer /usr/local besitzen sollte
@GabrielL. Welchen Teil verstehst du nicht? Wenn Sie verstehen, wie *nix-Berechtigungen funktionieren, und darüber nachdenken, wer in der Lage sein sollte, an zu schreiben /usr/local, sollte die Einrichtung selbstverständlich sein.
@MarnenLaibow-Koser — danke für die Antwort. Es ist nicht so, dass ich es nicht verstehe, so sehr, dass ich nicht weiß, was ich nicht weiß. ;-) Hauptsächlich habe ich versucht herauszufinden, was die potenziellen Nachteile/Nachteile dieses Ansatzes sein könnten. Es scheint ein guter Kompromiss zu sein.
@GabrielL. Homebrew schlägt diesen Weg in seinen FAQ vor, aber für eine "Multi-Uer-Umgebung".
@Marnen: Wir sollten beachten, dass Sie, da Catalina /usr/local ein Firmlink ist, keine ACL dafür erstellen können. Sie müssen es also für die Unterverzeichnisse tun. Ich habe es gerade ausprobiert und es funktioniert: /usr/local/bin ist root:wheel, aber die ACL für die Gruppe _brew erlaubt den Zugriff. Ihr eigenes Konto muss jedoch auch Mitglied dieser Gruppe sein. Und dann kann jeder Prozess, der als Ihr Benutzer ausgeführt wird, immer noch ohne Root-Rechte in diese Unterverzeichnisse schreiben. Wir brauchen eine Möglichkeit, damit es funktioniert, ohne Ihren eigenen Benutzer zu dieser Gruppe hinzuzufügen. Gibt es eine Möglichkeit, Ihren Benutzer zu einer Gruppe zu wechseln, der er nicht angehört?
Nein … streiche die letzte Frage: Wenn du deinen Benutzer zur Gruppe _brew hinzufügst, bleibst du immer noch im Team (20). Dann brew doctorwird Ihnen mitgeteilt, dass /usr/local/bin nicht beschreibbar ist. Wenn Sie mit zur Gruppe _brew wechseln newgrp brew, brew doctorwird /usr/local/bin nicht gekennzeichnet. Das ist also eigentlich eine ziemlich anständige Lösung.
PS nein, scheint nur in der ursprünglichen Terminall-Session funktioniert zu haben. Nach einer erneuten Anmeldung wird die Gruppe _brew akzeptiert, 501 und _brew sind "verheiratet", und Sie müssen die Gruppe nicht ändern, um nach /usr/local/bin zu schreiben ... also keine zusätzliche Sicherheit bei diesem Ansatz. Die ursprüngliche Frage bleibt also bestehen: Gibt es eine Möglichkeit, einen Benutzer zu einer Gruppe zu wechseln, der er nicht angehört?
@JayB Sie können einen Benutzer zu beliebigen Gruppen hinzufügen.
Sind meine Berechtigungen für /usr/local/ korrekt?
AntwortenHierDatenschutz-Bestimmungen1y, 0v