Sudo vs root; Irgendwelche tatsächlichen Unterschiede?


44

Ich arbeite mit einem Support-Mitglied für ein Produkt zusammen und er besteht darauf, dass ich root sein muss, um eine Reihe von Patches zu installieren, und dass sudo nicht funktioniert. Er gibt keinen Grund an, scheint aber in seinen Überzeugungen sehr fest zu sein. Browsing Superuser Ich kann keinen möglichen Grund dafür feststellen und bestätige dies, wenn ich Folgendes ausführe:

sudo -l

Ich bekomme:

...
User [MY USERNAME] may run the following commands on this host:
    (ALL) ALL

Der Zugriff des Linux / Server-Teams auf das Root-Verzeichnis ist meines Wissens kein sofortiger Vorgang. Daher würde ich es vorziehen, sie selbst zu installieren.

Gibt es einen praktischen Grund, warum sich sudo bei der Installation von Software auf einem Server anders verhält als root?


2
Ich denke, du solltest es ihm zurückwerfen. Wie andere gezeigt haben, gibt es unzählige Möglichkeiten, mit sudo Wurzeln zu schlagen, und wenn er Ihnen keinen konkreten Grund liefern kann, warum sudo nicht ausreicht, hat er kein Bein, auf dem er stehen kann.
Garrett

1
Umgebung und Unterbefehle kommen in den Sinn. Ich denke, Hastur hat gute Arbeit mit der Umgebung geleistet, und Jayen hat gute Arbeit mit Unterbefehlen, Piping und Umleitung geleistet.
Jww

2
Garrett hat einen guten Punkt, aber bevor ich in einen möglichen Piss-Wettbewerb geriet, würde ich das Support-Mitglied fragen: Hast du es auf beide Arten versucht und ist es auf eine dieser Arten gescheitert? Möglicherweise hat er den Fehler behoben, sudound die Skripte wurden gerade geschrieben. Wenn das der Fall ist, dann Antwort sds könnte sehr hilfreich sein für Sie: sudo su -.
Jww

Antworten:


34

Es hängt stark davon ab, wie Sie Ihr Programm mit sudooder aufrufen su.
ZB auf dem System, auf dem ich gerade bin:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1] 

Wobei [1] = / usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin
Env = Umgebungsvariablen werden für 1 und 5 zurückgesetzt, entnommen aus $ USER in 2,3,4.

So einen Skript oder ein Programm , das mit einer anderen Option gestartet wird , kann sehen , anders $PATH, $HOMEkann die Schale liest anders .bashrc, .profileund Umgebungsvariablen. Es liest die mit dem verknüpfte Datei $HOME. Jeder Benutzer kann seine Umgebung auf unterschiedliche Weise ändern (Variablen $PATH, .bashrc, .profile, .bash_profile, alias ...). Insbesondere kann ein Benutzer eine andere Reihenfolge der Verzeichnisse in seinem Verzeichnis haben $PATHund infolgedessen kann ein Skript einen Befehl ausführen, z. B. /home/$USER/binin dem Pfad, der von root erwartet wird.

Sie können das Programm unter ausführen, sudo -ials su -wären Sie als root mit angemeldet , aber Sie können ein anderes Verhalten haben, wenn Sie es mit sudo MyCommandoder mit ausführen su -c MyCommand.


Von man su:

Im Beschreibungsteil:
Die aktuelle Umgebung wird an die neue Shell übergeben . Der Wert von $ PATH wird zurückgesetzt auf / bin: / usr / bin für normale Benutzer oder / sbin: / bin: / usr / sbin: / usr / bin für den Superuser
...
In den Optionen Teil:
- , -l , --login
Eine Umgebung bereitstellen , die der vom Benutzer erwarteten Umgebung ähnelt, wenn der Benutzer direkt angemeldet ist .

Vom Menschen sudo

-i , --login Führt
die vom Kennwortdatenbankeintrag des Zielbenutzers angegebene Shell als Anmeldeshell aus. Dies bedeutet, dass anmeldungsspezifische Ressourcendateien wie .profile oder .login von der Shell gelesen werden. Wenn ein Befehl angegeben wird, wird er über die Option -c der Shell zur Ausführung an die Shell übergeben. Wird kein Befehl angegeben, wird eine interaktive Shell ausgeführt. sudoversucht, in das Ausgangsverzeichnis dieses Benutzers zu wechseln, bevor die Shell ausgeführt wird. Der Befehl wird in einer Umgebung ausgeführt, die der Umgebung ähnelt, die ein Benutzer beim Anmelden erhalten würde . Der Abschnitt Befehlsumgebung im Handbuch sudoers (5) dokumentiert, wie sich die Option -i auf die Umgebung auswirkt, in der ein Befehl ausgeführt wird, wenn die sudoers-Richtlinie verwendet wird.


Gute Antwort. Ich bin noch ein Anfänger bei Linux, aber gibt es einen weiteren Unterschied, der darin besteht, dass sudoIhre Möglichkeiten durch die Berechtigungen in der sudoers-Datei eingeschränkt werden können. Das letzte Blockzitat impliziert das vielleicht, aber wenn ich es richtig verstehe, scheint das ein weiterer wesentlicher Unterschied zu sein, der über die Umwelt hinausgeht (oder vielleicht wegen der Umwelt?).
Fixer1234

23

Wenn Sie vollen sudoZugriff haben, können Sie rootverwenden sudo su -, so dass der Sicherheitspunkt nicht mehr aktuell ist.

In der Tat gibt es eine Möglichkeit, den Unterschied zwischen einem Programm, das als ausgeführt wurde, rootund einem Programm, das unter sudoVerwendung von getuidvs ausgeführt wurde , zu erkennen, geteuidaber dies ist ein erfundener Trick. Warum sollte ein Patch-System das tun?


5
Apropos su -, er möchte möglicherweise verwenden, sudo -idamit er dieselbe Umgebung hat wie beim direkten Anmelden.
Cristian Ciupitu,

2
Wenn Sie zB mit ausführen, werden sudo myscriptSie $ PATH und Umgebungsvariablen von der Shell fernhalten, in der Sie sich befinden. Wenn Sie mit sudo -i myscriptIhnen laufen, laufen Sie, als ob Sie sich als root anmelden. Siehe die Antwort in unserem _zoo of calls :-) _
Hastur

1
Ich halte es für wichtig, darauf hinzuweisen, dass Umgebungsvariablen möglicherweise nicht so eingerichtet sind sudowie die Anmeldung als root
secretformula 21.06.14

1
@dmanexe: sudo steht nicht für superuser do, es ist "switch user do". Mit su und sudo können Sie zu beliebigen Benutzern und nicht nur zum Superuser wechseln. Auch gibt es nichts Pseudo über sudo, Sie bekommen wirklich die eigentliche Wurzel, wenn Sie sudo ausführen, einige haben nichts vorgetäuscht. Beachten Sie, dass die Magie von sudo wirklich von setuid permission bit herrührt.
Lie Ryan

2
sds, @CharlesDuffy: Die Idee , dass sudo und su Ursache geteuid()und getuid()von einem anders zu sein ein anderes ist ein Mythos. su und sudo ändern vor dem Ausführen des angegebenen Befehls oder der angegebenen Shell sowohl die realen als auch die effektiven Benutzer-IDs in die des Zielbenutzers, es sei denn, Sie haben sie ausdrücklich für ein anderes Verhalten konfiguriert. Sie können dies (für sudo) überprüfen, indem Sie sudo id -uund sudo id -ru(beide zeigen 0) ausführen , sudo (8) lesen (unter BEFEHLSAUSFÜHRUNG ) oder ein Testprogramm schreiben .

7

Es gibt ein paar Unterschiede, wenn Sie eine Root-Shell erhalten, wie von @Hastur hervorgehoben.

Wenn Sie keine Root-Shell erhalten, gibt es weitere Unterschiede. Das Support-Mitglied hat möglicherweise Erfahrung damit, Dinge zu tun, wie beispielsweise, sudo patch -p0 < /root/patch.filewo patches als root ausgeführt wird, aber nicht <(Piping aus einer Datei).


1
Richtig: Die praktische Sichtweise bietet oft Hinweise, die nur auf den Manpages schwer zu erkennen sind. Um eine ähnliche Situation zu überwinden, musst du mehr Sport treiben [:-)], z sudo /bin/bash -c "./patch -p0 < /root/patch". B. etwas wie schreiben . Noch heikler ist es, wenn Sie eine Datei mithilfe der Umleitung erstellen >. Auf die erste Weise erstellen Sie eine Datei, die dem Benutzer nur dann gehört, wenn Sie das Recht haben, in das endgültige Verzeichnis zu schreiben. In letzterer Weise erstellen Sie eine Datei, die root gehört ... die dunkle Seite von Unix ;-)
Hastur

1

Ich glaube, wenn Sie sudo-Zugriff verwenden, wird eine Protokolldatei erstellt, aber wenn Sie direkt über root-Zugriff ausgeführt werden, ist dies nicht der Fall.


0

Es hängt davon ab, wie feinkörnig der Root-Zugriff sein soll. Wenn Sie mehrere Benutzer haben, die unterschiedliche Aufgaben auf einem System ausführen, ist sudo idealer. Ein Beispiel, das ich häufig verwende, ist die Notwendigkeit, eine Anwendung oder eine Datenbank neu zu starten. Sicherheit wird am besten immer am wenigsten privilegiert. Ich benutze Gruppen und erlaube nur diesen Gruppen, explizite Aktionen auszuführen. Ein gutes Buch, das diesen Prozess beschreibt, ist "Sudo Mastery: Benutzerzugriffskontrolle für echte Menschen". Eigentlich ist es ein gutes Buch über Sudo im Allgemeinen ...

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.