it-swarm.com.de

Sudo vs root; Irgendwelche tatsächlichen Unterschiede?

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?

43
Nex Terren

Es hängt stark davon ab, wie Sie Ihr Programm mit Sudo oder su aufrufen.
Z.B. Auf dem System, auf dem ich in diesem Moment 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] 

Dabei ist [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.

Ein Skript oder ein Programm, das mit einer anderen Option gestartet wird, kann also unterschiedliche $PATH, $HOME, seine Shell unterschiedliche .bashrc, .profile und Umgebungsvariablen lesen. Es liest die Datei, die mit dem $HOME zusammenhängt. 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 $PATH haben, und folglich kann ein Skript einen Befehl ausführen, z. in /home/$USER/bin stattdessen den Pfad, der von root erwartet wird.

Sie können das Programm unter Sudo -i ausführen, da Sie als root mit su - angemeldet waren, aber Sie können ein anderes Verhalten haben, wenn Sie es ausführen mit Sudo MyCommand oder mit su -c MyCommand.


Von man su:

Im Beschreibungsteil:
Die aktuelle Umgebung wird an die neue Shell übergeben . Der Wert von $ PATH wird für normale Benutzer auf/bin:/usr/bin oder für den Superuser auf/sbin:/bin:/usr/sbin:/usr/bin zurückgesetzt
...
Im Optionsteil:
- , -l, --login
Stellen Sie eine Umgebung bereit, die der von dem Benutzer erwarteten ähnelt, wenn der Benutzer direkt angemeldet ist .

Vom Menschen Sudo

- i , --login
Führen Sie 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 ist, 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. Sudo versucht, 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.

33
Hastur

Wenn Sie vollen Sudo -Zugriff haben, können Sie mit Sudo su - zu root werden, sodass der Sicherheitspunkt umstritten ist.

In der Tat gibt es eine Möglichkeit, den Unterschied zwischen einem Programm, das als root ausgeführt wurde, und einem Programm, das unter Sudo ausgeführt wurde, zu erkennen. Verwenden Sie dazu getuid vs geteuid ist ein erfundener Trick. Warum sollte ein Patch-System das tun?

23
sds

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, Sudo patch -p0 < /root/patch.file auszuführen, wobei patch als root ausgeführt wird, < (Weiterleiten aus einer Datei) jedoch nicht.

7
Jayen

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.

1

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 ...

0
meredithkm