Kein /usr/sbin mehr im $Path nach Nutzerwechsel via su

[Cordess]

Mir ist heute aufgefallen, dass nach Eingabe von su und bestätigen mit dem root Passwort bei Debian Buster nun die Environmentvariablen von dem Nutzer übernommen werden, mit dem der su Befehl ursprünglich gestartet wurde.
D.h. obwohl man root ist, wird /usr/sbin nicht zum $PATH hinzugefügt. Bei Debian Stretch war das noch nicht so.

Meiner Meinung nach könnte das problematisch sein, wenn in der su Umgebung dann Paketinstallationen und vergleichbares durchgeführt werden, weil dann wichtige Befehle, die in /usr/sbin liegen, nicht mehr ausgeführt werden könnten.
dpkg-reconfigure befindet sich z.B. im /usr/sbin Verzeichnis, dieser Befehl funktioniert aber nicht bzw. kann nicht gefunden werden, wenn /usr/sbin/ nicht in der $PATH Variable drin steht.

Ob das also so eine gute Idee war, nach su die Env Variablen für root nicht richtig zu setzen?

Als Workaround empfehle ich in eine richtige Konsole via STRG+ALT+F?-Taste umzuschalten und sich als root dort einzuloggen, dann werden auch die Environmentvariablen richtig gesetzt und alles funktioniert wie gewünscht.
Der Nachteil ist dann halt, dass man nichts ablesen kann, was man gerade so auf dem Desktop angezeigt hat, wenn man da etwas braucht oder den Befehl nicht auswendig weiß.

[MaGe]

[...]D.h. obwohl man root ist, wird /usr/sbin nicht zum $PATH hinzugefügt. Bei Debian Stretch war das noch nicht so.[...]

(mit der Version 2.32-0.2 von util-linux vom 27. Juli 2018)
hat Debian auf eine andere su Implementierung umgestellt , siehe Fehler 833256
https://bugs.debian.org/cgi-bin/bugrepo ... bug=833256.
Das "neue" su stammt von util-linux während die "alte" im login Paket enthalten war

Debians altes su verhielt sich wie su - zumindest in Bezug auf PATH .
Mit der neuen Implementierung sollte man immer su - verwenden.



gruss MaGe

[DeletedUserReAsG]

Ob das also so eine gute Idee war, nach su die Env Variablen für root nicht richtig zu setzen?

Unbedingt: so kann man nun auswählen, ob man mit ›su‹ das Environment des Users behält, oder mit ›su -‹ das von Root lädt – incl. PATH.

[Cordess]

Mit der neuen Implementierung sollte man immer su - verwenden.

Danke für den Tipp.

Unbedingt: so kann man nun auswählen, ob man mit ›su‹ das Environment des Users behält, oder mit ›su -‹ das von Root lädt – incl. PATH.

Ich habe als su noch nie das Environment des Users benötigt. Wann brauchst du das?

[DeletedUserReAsG]

Ich habe als su noch nie das Environment des Users benötigt. Wann brauchst du das?

Ich könnte jetzt ’ne Situation konstruieren (Variablen für Ziel-/Konfigurationsverzeichnisse/-dateien von aufgerufener Software, etc.), weil ich selbst es tatsächlich bislang nicht gebraucht habe. Dennoch habe ich gerne die Wahl, und die habe ich nun. Wer ’n Problem mit den zwei zusätzlichen Tastendrücken hat, oder sich diese komplizierte Zeichenfolge nicht merken kann, dem steht’s ja frei, in der Konfiguration das alte Verhalten wiederherzustellen

[whisper]

Wenn ich ein tar sourcecode Paket
als User auspacke und dann ./configure && make ausführe,
kann ich mit su ein make install nachschieben, ohne erneut den Ordner zu betreten, denn ich stehe weiterhin dort drin.
Für make benötige ich nicht die env von root, im Gegenteil, evtl. von mir als user gesetzte configure Variable bleiben erhalten.