Ist es sicher, `/ usr / local` zu chownen?

Ich weiß, wozu es gut /usr/localist - Software für den lokalen Computer zu installieren. Standardmäßig rootbesitzt das Verzeichnis. Dies bedeutet, dass Sie zum Installieren dort verwenden müssen sudo. Für einen Einzelbenutzer- oder Entwicklercomputer scheint dies eine unnötige zusätzliche Verwendung des Befehls zu sein. Daher meine Frage - ist es sicher für mich zu besitzen /usr/local?

Zum Beispiel Homebrew für OS X "Just Works", weil sie ihre Software dort besitzen /usr/localund sicher installieren, ohne sie zu verwenden sudo.

Wenn Sie lokal kompilierte Software installiert haben /usr/local, benötigt die Software derzeit root, um sich selbst zu ändern oder Plugins zu installieren. Dies scheint unsicher - ich möchte nur verwenden, sudowenn ich genau weiß, was passieren wird.

Meinungen?

Ich kann nicht empfehlen, Eigentümer von zu werden /usr/local. In den meisten Situationen ist es wahrscheinlich weniger sicher als die Verwendung sudo.

Ihre Frage schlägt zwei Gründe vor, die Sie vielleicht möchten chown /usr/local.

Die erste besteht darin, die sudoInstallation von Software zu vermeiden . Dies könnte einigen (wie dem Autor dieser Antwort ) als Hinweis darauf dienen, dass Sie effizient arbeiten möchten, oder als Hinweis darauf, dass Sie die zum sudoEingeben und Eingeben Ihres Kennworts erforderlichen Tastatureingaben speichern möchten . Aber wahrscheinlich beziehen Sie sich, wenn Sie "unnötig" sagen, stattdessen auf das Prinzip des geringsten Privilegs :

Standardmäßig rootbesitzt das Verzeichnis. Dies bedeutet, dass Sie zum Installieren dort verwenden müssen sudo. Für einen Einzelbenutzer- oder Entwicklercomputer scheint dies eine unnötige zusätzliche Verwendung des Befehls zu sein

Ich höre / lese ziemlich oft Leute, die nach dem Motto "Ich bin der Einzige, der dieses System benutzt, also sollte ich kein sudoPasswort verwenden und eingeben müssen." Für Leser, die dieser Ansicht sind, und weil es hier relevant ist, wollen wir uns an einen grundlegenden Sicherheitsgrund erinnern, aus dem root Dinge besitzt.

Die meisten Programmdateien, die auf einem Ubuntu-System installiert sind, haben den Dateimodus 755 oder in symbolischer Notation rwxr-xr-x, was bedeutet, dass jeder Benutzer oder jedes Programm sie ausführen kann , aber nur der Eigentümer der Dateien, root, kann sie ändern. (Technisch erfordert dies auch, dass niemand außer root die wBerechtigung für das Verzeichnis hat, das sie enthält, damit andere Benutzer sie nicht löschen oder verschieben können.)

Dies bedeutet, dass Sie als bescheidener Benutzer jedes Programm ausführen können. Wenn Sie versuchen, ein Programm zu verwenden, um etwas zu tun, für das Sie keine Berechtigung haben, z. B. einen Schreibvorgang für eine Datei im Besitz von root, tritt ein Fehler auf. Dadurch ist es weniger wahrscheinlich, dass ein Tippfehler in einem Befehl, einer fehlerhaften Anwendung oder einem bösartigen Code Ihr System durcheinander bringt. Solange es nicht als root ausgeführt wird, hat es keine Berechtigung dazu. Dies ist besonders nützlich, wenn Sie Programme ausführen, die mit dem Internet interagieren.

Wenn Sie dies tun chown /usr/local, kann jedes Programm, das mit Ihren Berechtigungen ausgeführt wird, Dateien dort schreiben, die später möglicherweise als root ausgeführt werden, z. B. durch Ersetzen eines anderen Befehls mit demselben Namen. /usr/local/binist in der Standardeinstellung $PATHund in sudo's secure_pathund steht vor anderen Speicherorten in beiden. Also, wenn ich zwei ausführbare Dateien habe

/usr/local/bin/chown
/bin/chown

wenn ich ausführen sudo chown ..., die chownin /usr/local/binwird ausgeführt .

Aber das wussten Sie wahrscheinlich schon, denn Ihr zweiter Grund ist die Sicherheit:

Wenn Sie lokal kompilierte Software installiert haben /usr/local, benötigt die Software derzeit root, um sich selbst zu ändern oder Plugins zu installieren. Dies scheint unsicher - ich möchte nur verwenden, sudowenn ich genau weiß, was passieren wird.

_{Nur für den Fall, dass es notwendig ist, dies hier zu erwähnen, ist es absolut richtig (laut FHS sowieso), lokal kompilierte Software zu installieren /usr/local, aber das Kompilieren selbst sollte irgendwo in Ihrem $HOME, ohne sudo, bis zum letzten Schritt, wenn Sie sudo make installoder Äquivalent eingeben, erfolgen.}

Ich denke, Sie schlagen vor, dass Sie durch Ausführen eines Programms, das /usr/localals nicht privilegierter Eigentümer installiert ist , bestimmte Berechtigungsfehler verwenden könnten, wenn es versucht, sich selbst zu aktualisieren, um festzustellen, ob es versucht, einen anderen Dateisystemspeicherort zu ändern, dessen Eigentümer Sie nicht sind Ich will nicht, damit du es daran hindern kannst.

Das könnte hilfreich sein. Die Implikation ist, dass Sie dem Programm vertrauen, alles zu tun, was es möchte /usr/local, aber nicht woanders. Wenn erhöhte Berechtigungen angefordert werden, können Sie die Aktualisierung oder Deinstallation verweigern. Das ergibt für mich einen Sinn. Aber ich denke /usr/local, es ist wahrscheinlich keine gute Idee, auf diese Weise eine Art Sandbox zu verwenden , oder es ist zumindest unwahrscheinlich, dass dies die sicherste Lösung ist. Es ist kein richtig isolierter Ort ( /optist etwas isolierter, da dies nicht die Standardeinstellung ist $PATH). Das Programm könnte etwas schreiben oder löschen /usr/local, um Schaden zu verursachen. Andere (möglicherweise schlecht geschriebene) Programme, die Sie ausführen, können dort Code schreiben und ausführen, von dem Sie nichts wissen.

Wenn Sie befürchten, dass sich ein Programm selbst sicher aktualisiert, sollten Sie nach Alternativen suchen (möglicherweise programmspezifisch, wie z. B. bei Python, oder Sie könnten nach einem Snap oder einer ähnlichen Implementierung suchen, die Ihren Anforderungen entspricht oder diese verwendet Container oder eine VM, um potenziell unsichere Software zu testen), bevor ein Systemspeicherort (auch ein relativ benutzerfreundlicher) bereitgestellt wird, auf den Programme schreiben, die von einem normalen Benutzer ausgeführt werden. Das scheint mir ebenso unvorhersehbare Auswirkungen zu haben wie das Zulassen von Programmen mit vorübergehend erhöhten Berechtigungen sudo.

Es ist ungewöhnlich, dass /usr/localnicht im Besitz von root. Sie können den Eigentümer jedoch beliebig ändern.

Ich empfehle jedoch sicherzustellen, dass /usr/local/sbines sich immer noch im Besitz von befindet root, um ein Sicherheitsproblem zu vermeiden. Die Befehle hier werden normalerweise nur von root aufgerufen.

Verwenden Sie für Software, die nur Sie benötigen, Ihr Basisverzeichnis anstelle von /usr/local.

Anstatt den Besitz von /usr/localBefehlen zu ändern oder Befehle als root ausführen zu müssen, wenn Sie dies nicht möchten, sollten Sie Ihre Builds nur so konfigurieren, dass sie in Ihrem Ausgangsverzeichnis installiert werden, anstatt /usr/local. Hiermit werden alle potenziellen Probleme beim Ändern des Eigentums an behoben /usr/local, einschließlich der Art binund Weise, in der sich die sbinVerzeichnisse und Unterverzeichnisse im rootPfad befinden.

Wenn Sie anderen Benutzern erlauben müssen, Ihre Software auszuführen, können Sie ihnen Zugriff gewähren. In der Tat werden sie wahrscheinlich bereits in der Lage sein, da Ihr Home-Verzeichnis standardmäßig über einen zulässigen Lese- und Ausführungszugriff verfügt . (Wenn Sie das nicht möchten, können Sie es ganz einfach ändern, indem chmodSie die Dateien oder Verzeichnisse verwenden, die Sie als privat kennzeichnen möchten, und möglicherweise auch Ihre ändern umask.)

Wenn die Software in Ihrem Ausgangsverzeichnis installiert ist, /usr/local/binwerden stattdessen Binärdateien verwendet, die eingegangen wären . Sie erhalten andere Unterverzeichnisse Ihres Home-Verzeichnisses, die den Unterverzeichnissen der von Ihnen installierten Software entsprechen. Dies geschieht normalerweise automatisch, wenn Sie Software aus dem Quellcode installieren./home/username/bin/usr/local

Konfigurieren Ihrer Builds

Die meiste Software, die Sie aus Quellcode erstellen, hat einen Schritt, in dem Sie Folgendes ausführen:

./configure

Für die große Mehrheit der Software, die mit einem configureSkript geliefert wird, das so ausgeführt werden kann, wird standardmäßig der Build für die Installation konfiguriert, /usr/localwenn Sie ihn schließlich ausführen sudo make install, um ihn zu installieren. Der Grund ist, dass es implizit gleichbedeutend mit dem Ausführen von:

./configure --prefix=/usr/local

Verwenden Sie stattdessen Folgendes, um einen Build für die Installation in Ihrem Ausgangsverzeichnis zu konfigurieren:

./configure --prefix="$HOME"

In der Praxis enthalten Homeverzeichnis-Pfade in Ubuntu keine Leerzeichen, andere Leerzeichen oder andere Zeichen, die von der Shell speziell behandelt *werden. Wenn Sie also Ihr Benutzerkonto nicht recht merkwürdig eingerichtet haben, können Sie einfach Folgendes eingeben:

./configure --prefix=$HOME

(Ich empfehle jedoch nicht, sich daran zu gewöhnen, Skripte zu schreiben . Bei einigen anderen Betriebssystemen, wie z. B. macOS, ist es weniger ungewöhnlich, dass die Pfade zu den Basisverzeichnissen der Benutzer Leerzeichen enthalten.)

Wenn Sie möchten, können Sie auch Ihren vollständigen Pfad zum Basisverzeichnis eingeben:

./configure --prefix=/home/username

(Ersetzen usernameSie dies natürlich durch Ihren tatsächlichen Benutzernamen. Wenn Ihr Ausgangsverzeichnis aus irgendeinem Grund nicht vorhanden /homeist, müssen Sie es entsprechend anpassen.)

Installieren Ihrer Builds

Nachdem Sie ausgeführt haben make, sind Sie möglicherweise an das Ausführen gewöhnt sudo make install, aber wenn Sie in Ihrem eigenen Ausgangsverzeichnis installieren, müssen Sie es nicht als Root ausführen, sodass Sie es beenden können und solltensudo . Lauf einfach:

make install

Ebenso für Software, die ein uninstallZiel unterstützt :

make uninstall

Dies ist genau das, wonach Sie gefragt haben ... nur in Ihrem Home-Verzeichnis, nicht /usr/local.

Ausführen Ihrer Programme

Wahrscheinlich ist das binUnterverzeichnis Ihres Home-Verzeichnisses entweder:

• schon in deinem $PATH, oder
• wird in Ihrem sein, $PATHwenn Sie sich nur aus- und wieder anmelden.

Der Grund dafür ist, dass die .profileDatei in Ihrem Ausgangsverzeichnis , die Befehle enthält, die beim Anmelden ausgeführt werden, diese standardmäßig für Benutzerkonten enthält, die in den meisten Versionen von Ubuntu erstellt wurden (einschließlich des ersten Administratorkontos, das beim Installieren des Betriebssystems erstellt wurde):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Dieser Code wird ausgeführt, wenn Sie sich anmelden (weil er angemeldet ist .profile) und legt Ihr persönliches binVerzeichnis $PATH nur dann ab, wenn es zu diesem Zeitpunkt vorhanden ist. Deshalb müssen Sie sich möglicherweise abmelden und wieder anmelden.

Ältere Releases wie Ubuntu 14.04 sowie neuere Releases wie Ubuntu 17.10 sind ebenfalls enthalten. Ubuntu 16.04, das zum Zeitpunkt des Schreibens wahrscheinlich beliebteste Release, hat jedoch stattdessen Folgendes:

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

Das fügt einfach das binUnterverzeichnis Ihres Home-Verzeichnisses - sowie das .local/binUnterverzeichnis - zu Ihrem hinzu $PATH, ohne zu überprüfen, ob diese Verzeichnisse tatsächlich existieren. Wenn Sie also 16.04 verwenden oder ein Upgrade von einem System durchführen, das 16.04 war, als Ihr Benutzerkonto erstellt wurde, befindet sich das binUnterverzeichnis Ihres Home-Verzeichnisses wahrscheinlich bereits in Ihrem $PATH.

Ihre .profileDatei wird aus dem /etc/skelVerzeichnis kopiert, wenn Ihr Benutzerkonto erstellt wird. Wenn Ihr Benutzerkonto mit einer älteren Ubuntu-Version erstellt wurde, hat es diese Version von erhalten .profileund wurde für Ihr Benutzerkonto durch ein Upgrade auf eine neuere Version nicht geändert.

Sobald sich das binUnterverzeichnis Ihres Home-Verzeichnisses in Ihrem befindet $PATH, können Sie Programme ausführen, deren ausführbare Dateien dort installiert sind, indem Sie einfach deren Namen eingeben, genau wie Sie es mit Programmen tun könnten, die vom Ubuntu-Paketmanager installiert oder in diesem installiert wurden /usr/local.

Die .localOption

Möglicherweise haben Sie bemerkt, dass die Standarddatei .profilefür Benutzerkonten, die in einigen Ubuntu-Versionen erstellt wurden, einschließlich 16.04, wie oben beschrieben, nicht nur $HOME/binIhren Pfad erweitert, sondern auch $HOME/.local/bin. Wenn Sie .profiledas nicht hinzufügen, aber möchten , können Sie es einfach bearbeiten.

Obwohl häufig zum Speichern von Einstellungen und zwischengespeicherten Daten verwendet , können Sie Software auch im .localUnterverzeichnis Ihres Basisverzeichnisses installieren . Sie sollten sich dabei ungehemmt fühlen, da dies in Bezug auf Benutzerfreundlichkeit und Sicherheit --prefix="$HOME/.local"ähnlich ist wie --prefix="$HOME".

Denken Sie daran, dass Dateien und Verzeichnisse, die mit beginnen ., in grafischen Dateibrowsern nicht standardmäßig angezeigt werden (verwenden Sie Ctrl+, Hum sie ein- und auszublenden) oder über den lsBefehl (übergeben Sie das Flag -Aoder -a, um sie anzuzeigen ). Dies ist möglicherweise nicht das, was Sie möchten, oder es ist möglicherweise genau das, was Sie möchten. Dies ist eine Frage der persönlichen Präferenz.

Ich habe jedoch beobachtet, dass einige automatisierte quellbasierte Paketmanager, die Software im eigenen Heimverzeichnis erstellen und installieren, diese verwenden $HOME/.local. Ich weiß nicht genau, wie häufig dies vorkommt - ich hoffe, dass ich es weiter untersuchen und diese Antwort aktualisieren kann -, aber vielleicht bevorzugen Sie es, sie nur $HOMEfür manuell kompilierte Aufgaben zu verwenden. Auf diese Weise wird klar, woher die Dinge kamen. Und wenn es zu einer Kollision kommt, ist es wahrscheinlich, dass die Software weiterhin akzeptabel koexistiert.

Sie können auch absichtlich Software in $HOME/.localund andere Software in installieren $HOME. Es liegt an dir. Das binVerzeichnis, das zuerst in Ihrer $PATHUmgebungsvariablen angezeigt wird, ist dasjenige, von dem aus ein Befehl ausgeführt wird, falls in beiden Befehlen derselbe Name vorhanden ist.

Kredit geht an Zanna und Videonauth für den Hinweis auf Fehler in einer früheren Version dieser Antwort in Bezug auf die Ubuntu - Releases , die Standard - Code in .profileund hilft mir zu korrigieren sie (siehe auch hier ).

Wenn sudo eine solche Unannehmlichkeit ist, aktualisieren Sie einfach / etc / sudoers, damit Sie Ihr Passwort nicht eingeben müssen, wenn Sie sudo ausführen. Ich glaube, das ist eine bessere Lösung als den Besitzer von / usr / local zu ändern.