Ich verwende HomeBrew für meine Portanforderungen (scheint etwas „sauberer“ als MacPorts zu sein).
Ich kann ohne sudo
ing installieren (was großartig ist), aber der Man-Linking-Schritt scheint dies zu erfordern ( /usr/local/share/man/man3
im Besitz von root
).
Eine Anleitung, die ich gefunden habe, schlägt vor, dass ich rekursiv chown /usr/local
tue
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
Es ist normalerweise besser, die Berechtigungen so streng wie möglich zu halten. Besitz behalten /usr/local
durch root
bedeutet, 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/local
und Ihren Pfad, Manpath usw. ändern, um die Verzeichnisse darunter einzuschließen.
Eine bessere Möglichkeit besteht darin, einen anderen Benutzer anzulegen – sagen wir, homebrew
und 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 root
und 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/local
und ersetzen sie durch das ausgewählte Verzeichnis, von dem ich vermute, dass wir bei stecken bleiben /usr/local
.
$PATH
und einzuschließen. $MANPATH
Wenn die installierten Programme keine systemweite Installation erfordern, ist dies eine viel bessere Alternative.brew doctor
(unten vorgeschlagen) sagte mir, dass ich nur die Shared Man-Verzeichnisse chownen muss ... sicher genug für mich.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
Es ist einfacher
/usr/local/bin
ist bereits in IhrerPATH
.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.- Es ist sicher,
dass Apple sich an POSIX angepasst und dieses Verzeichnis für uns hinterlassen hat. Das bedeutet, dass/usr/local
standardmäß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 chown
ing /usr/local
nicht 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 doctor
können Ihnen helfen!
brew doctor
ist einfach genial.admin
Wenn 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 brew
Kommando 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.
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.Für das, was es wert ist, /usr/local
wird 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 install
anderen Software oder der Eingabe Ihres Passworts nach einem Doppelklick auf eine .pkg
, die Daten in /usr/local
.
Der Besitz /usr/local
hat ü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 .)
/usr/local/bin
ist 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/man
derzeit für das Setup von OP gelten, kann jeder gehen und jede Binärdatei mit einem Skript ändern, das dies tut rm -rf ~
./usr/local
sollten 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
brew update
, was immer noch den Besitz von erfordert /usr/local
. Ich werde versuchen, die Berechtigungen danach wiederherzustellen.Kann ab macOS High Sierra oder neuer /usr/local
nicht 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 sudo
jedes 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.
/usr/local/bin
es 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.sudo
aus, 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.~/brew
oder so installieren. Das Problem ist jedoch, dass im Gegensatz zu Ruby, das ziemlich eigenständig ist, viele *nix-Dienstprogramme erwarten, sich in /usr/local
.../usr/local
nicht 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_inherit
total rock). Dies ist der beste Kompromiss, den ich finden konnte: keine sudo
On-Build-Skripte, aber etwas Kontrolle über /usr/local
./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/local
oder 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?/usr/local
, sollte die Einrichtung selbstverständlich sein.brew doctor
wird Ihnen mitgeteilt, dass /usr/local/bin nicht beschreibbar ist. Wenn Sie mit zur Gruppe _brew wechseln newgrp brew
, brew doctor
wird /usr/local/bin nicht gekennzeichnet. Das ist also eigentlich eine ziemlich anständige Lösung.
Mike McQuaid
Slipp D. Thompson
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ührensudo find /usr/local -perm -200 -exec chmod g+w '{}' \+
, um sicherzustellen, dass die Gruppe denselben Schreibzugriff wie der Benutzer hat.Gefängnis
Schirmherrschaft
oem1905
oem1905