Warum unterscheiden sich PATH-Variablen bei der Ausführung über sudo und su?

Wenn ich auf meiner Fedora-VM mit meinem Benutzerkonto ausgeführt werde, habe ich Folgendes /usr/local/binin meinem Pfad:

[justin@justin-fedora12 ~]$ env | grep PATH
 PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Und ebenso beim Laufen su:

[justin@justin-fedora12 ~]$ su -
Password: 
[root@justin-fedora12 justin]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Bei Ausführung über sudobefindet sich dieses Verzeichnis jedoch nicht im Pfad:

[root@justin-fedora12 justin]# exit
[justin@justin-fedora12 ~]$ sudo bash
[root@justin-fedora12 ~]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin

Warum sollte der Pfad beim Laufen über anders sein sudo?

Schauen Sie sich an /etc/sudoers. Die Standarddatei in Fedora (sowie in RHEL und auch in Ubuntu und ähnlichem) enthält folgende Zeile:

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Dies stellt sicher, dass Ihr Pfad sauber ist, wenn Sie Binärdateien unter sudo ausführen. Dies schützt vor einigen der in dieser Frage genannten Bedenken . Es ist auch praktisch, wenn Sie nicht /sbinund /usr/sbinauf Ihrem eigenen Weg haben.

Der Befehl su -führt das Root-Benutzerprofil aus und übernimmt die Umgebung dieses Benutzers, einschließlich des Pfads usw. sudo, was nicht der Fall ist.

Wenn Sie sich so sudoverhalten möchten, su -verwenden Sie die Option, mit sudo -i [commandder das Benutzerprofil ausgeführt wird

Wenn Sie sich so su -verhalten möchten, verwenden sudoSie nicht den Bindestrich, sondern nursu [command]

Sie können überprüfen, warum (es ist anders), indem Sie ausführen sudo sudo -V.

Zum Beispiel unter Linux:

$ sudo sudo -V | grep PATH
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

^{Hinweis: Bei macOS / BSD, nur laufen: sudo sudo -V.}

Die obige Liste ist aufgrund des Standardsicherheitsrichtlinien-Plugins in einigen Linux-Distributionen eingeschränkt.

Dies wird weiter erläutert in man sudoers:

Wenn die secure_pathOption gesetzt ist, wird ihr Wert für die PATHUmgebungsvariable verwendet.

secure_path- Pfad, der für jeden Befehl verwendet wird, der von sudo ausgeführt wird. Wenn Sie den Leuten, die sudo ausführen, nicht vertrauen, dass sie eine vernünftige PATHUmgebungsvariable haben, können Sie diese verwenden.

Eine andere Verwendung ist, wenn Sie möchten, dass der „Stammpfad“ vom „Benutzerpfad“ getrennt ist. Benutzer in der durch die exempt_groupOption angegebenen Gruppe sind nicht betroffen secure_path. Diese Option ist standardmäßig nicht aktiviert.

Wenn dies der Fall ist, können Sie dies ändern, indem Sie sudo visudodie Konfigurationsdatei ausführen und bearbeiten und Ihren secure_path(durch getrennten :) zusätzlichen Pfad ändern oder Ihren Benutzer hinzufügen exempt_group(damit Sie nicht von den secure_pathOptionen betroffen sind ).

Oder PATHSie können Folgendes ausführen, um die temporäre Gültigkeit des Benutzers zu beenden:

sudo env PATH="$PATH" my_command

und Sie können das überprüfen, indem Sie:

sudo env PATH="$PATH" env | grep ^PATH

Siehe auch: Wie macht man sudoKonserven $PATH?

Ein weiterer Grund, warum die Umgebung anders sein könnte sudo, ist, dass env_resetin Ihrer sudoersDatei möglicherweise die Option aktiviert ist . Dadurch werden Befehle in einer neuen, minimalen Umgebung ausgeführt.

So können Sie die env_keepOption (aus Sicherheitsgründen nicht empfohlen ) verwenden, um die Umgebungsvariablen Ihres Benutzers zu erhalten:

Defaults        env_reset
Defaults        env_keep += "PATH PYTHONPATH"

In den meisten Linux-Betriebssystemen installieren Sie Programme über die Paketverwaltung und erhalten regelmäßig Updates. Wenn Sie etwas installieren, das die Paketverwaltung umgeht, wird es in / usr / local / bin installiert (z. B. oder ... / sbin oder / opt) und erhält keine regelmäßigen Updates.

Ich denke daher, dass die Programme nicht als so sicher angesehen werden und nicht standardmäßig in Roots PATH abgelegt werden.

Ich habe das gerade selbst ausprobiert und habe das Verhalten, das Sie gesehen haben, nicht gesehen - mein Pfad ist derselbe geblieben, also ist Ihre Sudo-Konfiguration möglicherweise anders. Wenn Sie überprüfen, dass man sudoersSie sehen, gibt es eine Option namens secure_pathZurücksetzen PATH- es klingt, als wäre diese Option aktiviert worden.

Denn wenn Sie verwenden sudo bash, bashfungieren Sie nicht als Login-Shell. Versuchen Sie es erneut mit sudo bash -lund Sie sollten das gleiche Ergebnis sehen wie su -.

Wenn das richtig ist, dann ist die Differenz in PATHliegt in den Konfigurationsdateien: /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profileausgeführt wird (in dieser Reihenfolge) für ein Login - Shell, während ~/.bashrcfür eine Nicht-Login interaktiv Shell ausgeführt wird.

Alte Frage, ich weiß, aber ich bin gerade hier reingestolpert, weil ich genau diesem Problem nachgegangen bin.

Aus irgendeinem Grund /usr/local/binwar nur in der PATH als root via sudo su -. Bei der Verwendung war sudo -ies nicht da. Natürlich weiß ich jetzt, dass ich es zu / etc / sudoers hinzufügen kann, aber das hat immer noch nicht erklärt, warum es danach schon da ist su -. Woher kommt dieser Teil von PATH?

Nach langem Stöbern und Suchen fand ich die Antwort:

Der Standardpfad mit '/ usr / local / bin' ist in su (1) fest codiert.

Daher war keine Pam-Konfiguration, kein Profil, kein bashrc oder etwas anderes für das selektive Hinzufügen dieses Elements verantwortlich. Es war immer schon da, als es suübernommen wurde. Und da es sudoüberhaupt nicht aufgerufen wird, susondern seine eigene Konfiguration verwendet, hat es danach gefehltsudo -i

Ich fand, dass dies auf RHEL6 und RHEL7 zutrifft. Ich habe keine andere Version oder Distribution überprüft.