Warum kann sudo einen Befehl nicht finden, den ein normaler Benutzer finden kann?

Warum kann sudo einen Befehl nicht finden, den ein normaler Benutzer finden kann?

Vor einiger Zeit habe ich NPM installiert und dabei festgestellt, dass beim Versuch, das Shell-Installationsskript mit sudo auszuführen, Fehler auftraten, weil einige Befehle nicht gefunden wurden. Beim Versuch, dasselbe Skript ohne sudo auszuführen, funktionierte jedoch alles wie am Schnürchen.

Ich bin ein neuer Linux-Benutzer, aber nach meinem Verständnis sind die Berechtigungen und die Sichtbarkeit von sudo eine Obermenge der Berechtigungen eines normalen Benutzers.

Warum passiert das?

Antwort1

Meines Wissens nach sind die Berechtigungen und die Sichtbarkeit von sudo eine Obermenge der Berechtigungen eines normalen Benutzers.

Berechtigungen, ja, aber nicht unbedingt Sichtbarkeit. Die Sichtbarkeit von Anwendungen wird durch die PATHUmgebungsvariable geregelt

~$ printenv PATH
/home/vanadium/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/games

Wenn ein Befehl eingegeben wird, prüft der Befehlsinterpreter zunächst, ob es sich um einen internen Befehl handelt oder ob der Befehl dem Namen einer ausführbaren Datei auf der Festplatte entspricht. Anschließend durchsucht das System die in aufgeführten Verzeichnisse, PATHbis eine ausführbare Datei mit einem Namen gefunden wird, der dem Befehl entspricht.

Wie Sie im Beispiel sehen, kann ein Benutzer zusätzliche private Verzeichnisse im haben PATH, die nur durchsucht werden, wenn dieser Benutzer den Befehl ausgibt. Daher kann ein Benutzerkonto über andere Befehle verfügen als der rootBenutzer, d. h. der Administrator, die Rolle, die er bei Verwendung des sudoBefehls einnimmt.

Dennoch bestimmen letztlich die Berechtigungen einer ausführbaren Datei, wer die Datei ausführen kann. Sofern die Berechtigungen es zulassen, kann eine ausführbare Datei immer ausgeführt werden, indem in der Eingabeaufforderung der vollständige Pfadname angegeben wird, z. B. /usr/bin/mountstatt nur des Dateinamens mount. Und tatsächlich rootkann sie immer ausgeführt werden, solange das Ausführbarkeitsbit gesetzt ist, selbst wenn dies nur für den Eigentümer gilt.

Antwort2

Angenommen, Sie möchten eine Datei in Ihrem Verzeichnis scripts ausführen. Sie würden Folgendes ausführen:

myscript.sh

und das Skript läuft einwandfrei. Aber nachdem Sie sudo ausgeführt haben, erhalten Sie folgenden Fehler:

sudo: myscript.sh: file not found

Wenn sudo verwendet wird, wird der Pfad des Root-Benutzers verwendet. Die Lösung hierfür wäre, den Befehl folgendermaßen auszuführen:

sudo ./myscript.sh

Antwort3

Die Shell (Bash usw.) verwendet im normalen Benutzermodus und im Sudo-Modus unterschiedliche Variablen. Überprüfen Sie dies einfach, indem Sie das folgende Verfahren befolgen:

# Plain user
printenv > env1
# Using sudo
sudo printenv > env2
# Comparison
diff env1 env2
# Alternative comparison using the GUI tool meld
meld env1 env2

Wenn Meld nicht installiert ist, können Sie es einfach installieren. Es ist sehr nützlich.

sudo apt-get update
sudo apt-get install meld

Unterschiedliche Inhalte der Variablen des einfachen Benutzers/Sudo können das Shell-Verhalten und die Skriptfunktionalität beeinflussen.

Auch die Dateizugriffsberechtigungen sind unterschiedlich.

Antwort4

Tatsächlich ist es ein bisschen komplizierter. Es gibt einige Definitionen, die vorhanden sein müssen /etc/sudoers.

Die Steuerflags, die bestimmen, was mit der sudoUmgebung geschieht, sind: env_check, env_keep, und env_reset.

DerManpage für Sudoerserklärt dies sehr gut im Abschnitt „Befehlsumgebung“:

$ man --pager="less -p '^\ *Command environment'" sudoers

In einer vorkonfigurierten Ubuntu-Konfiguration PATHwird das für definierte Flag aufgerufen secure_path(standardmäßig aktiviert). Der Wert wird anstelle des PATHzu startenden Benutzers verwendet sudo, weil env_resetebenfalls standardmäßig aktiviert ist:

$ man sudoers | egrep "^\ *secure_path" -A4 | sed 's/^ *//'

secure_path   If set, sudo will use this value in place of the user's PATH environment variable. This option can be used to reset the PATH to a known good
value that contains directories for system administrator commands such as /usr/sbin.

Users in the group specified by the exempt_group option are not affected by secure_path.  This option is not set by default.

(Bearbeiten: Die letzte Zeile oben bezieht sich darauf, dass das exempt_groupnicht standardmäßig aktiviert ist, nicht auf das secure_path)

Sie können es wie folgt ändern visudo(empfohlen) oder anzeigen:

$ sudo grep secure_path /etc/sudoers
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

In anderen Fällen sind die Befehle in Bash integriert (wie echo) und keine ausführbare Datei, auf die Sie in einer PATHVariablen verweisen können. In diesen Fällen müssen Sie einen Wert in eine sudo bash -coderandere Möglichkeiten.

verwandte Informationen