staging.inyokaproject.org

Ich kann den Fall nicht herstellen, daß sudo/root ungewollt in den Benutzer schreibt. Auch macht es doch keinen Unterschied, ob GUI oder nicht, solange, und das ist doch der Normalfall mit relativen Pfaden gearbeitet wird. Soll heißen das Problem bestand vorher auch bei den nicht GUIs.

momentan:

sudo <irgendwas>
sudo <terminal>

wird offb. immer als root ($USER) und in Dessen Verzeichnis /root ($HOME) ausgeführt.

echo $USER $HOME; pwd

Ich kann, wie gesagt kein Verbiegen provozieren.

–

sudo pwd /home/klaus $ sudo -H pwd /home/klaus

Ist Das nicht so normal?, pwd zeigt nur das momentane Arbeitsverzeichnis. Da kann doch auch root sein.

Wogegen

sudo -i

doch wohl zur root Shell Umgebung führt. Also damit liegt der relative Pfad bei root.

–

Hallo,

das hat direkt nichts mit relativen Pfaden zu tun. Mit der Option -H wird die Umgebungsvariable für HOME gesetzt. In deinem Beispiel fragst du aber das Working Directory ab. Das muss nicht HOME für den aktuelle Benutzer sein, das ist unabhängig voneinander.

Gruß, noisefloor

Das Thema war ein Anderes.

War nicht gut, Das aus dem Zusammenhang zu reissen. Weder speziell um sudo -H, noch pwd ging es. Werde Das auf Gelöst stellen.

Das Problem bei der Verwendung von

sudo -H 

ist, dass das Arbeitsverzeichnis nicht gesetzt wird, sondern nur die Umgebungsvariable HOME.

Normalerweise ist ein Arbeitsverzeichnis gesetzt, oft ist dieses das Benutzerverzeichnis und es kann per pwd abgefragt werden und auch als Inhalt der Umgebungsvariablen HOME und PWD angezeigt werden:

$ pwd
/home/klaus
$ printenv | grep -e HOME -e PWD
PWD=/home/klaus
HOME=/home/klaus

Jedoch:

$ sudo -H pwd
/home/klaus
$ sudo -H printenv | grep -e HOME -e PWD
HOME=/root

sudo -H setzt nicht das Arbeitsverzeichnis auf das Benutzerverzeichnis des neuen Benutzers root. Es ist sogar gar kein Arbeitsverzeichnis gesetzt. Wenn jetzt eine Datei geschrieben werden soll und dabei kein absoluter Pfad verwendet wird, ist das Ergebnis unvorhersagbar. Oft wird im Benutzerverzeichnis des alten Benutzers für eine Datei als Besitzer root eingetragen und wenn dies z.B. .Xauthority betrifft, wird der Desktop unbenutzbar. Also bitte niemals

sudo -H GUI-Programm 

und schon gar nicht:

sudo GUI-Programm 

Es ist richtig, dass so etwas auch bei Nicht-GUI-Programmen geschehen kann. Ich habe z.B. gerade bei mir gefunden:

$ find ~ ! -user $USER -ls
       77      4 -rw-------   1 root     root           74 Aug 30  2020 /home/klaus/.wpa_cli_history

Ergebnis eines früheren Befehls:

sudo wpa_cli 

und wpa_cli ist kein GUI-Programmm. Die Folgen sind hier aber nicht dramatisch; bei GUI-Programmen jedoch fatal.

sudo schreibt übrigens bei jedem Aufruf ins Benutzerverzeichnis:

$ rm -f ~/.sudo_as_admin_successful 
$ ls -l .sudo*
ls: Zugriff auf '.sudo*' nicht möglich: Datei oder Verzeichnis nicht gefunden
*** Fehlercode: 2 ***
$ sudo false
*** Fehlercode: 1 ***
$ ls -l .sudo*
-rw-r--r-- 1 klaus klaus 0 Nov 28 14:12 .sudo_as_admin_successful

Diese Datei ist jedoch harmlos. Aber was macht sudo noch als Nebeneffekt, was man nicht weiß?

kB schrieb:

Also bitte niemals

sudo -H GUI-Programm 

Das überrascht mich persönlich jetzt doch etwas, da sudo -H ...

z.B. ... hier (im Artikel "Sudo") ...

Die Option -H bewirkt, dass dann auch die Umgebungsvariabele $HOME auf das Home-Verzeichnis von BENUTZERNAME mit umzieht, was beim Starten von grafische Programme wichtig ist.

... und hier (im Artikel "mit_Root-Rechten_arbeiten/#sudo") ...

Beim Ausführen von Programmen sollte sicherheitshalber sudo immer mit der Option -H aufgerufen werden.

... sowie regelmäßig im Forum empfohlen wird.

ser:kB:] schrieb:

und schon gar nicht:

sudo GUI-Programm 

Das war mir bisher klar, aber das zuvor ...

Gruß, Holger

sudo -H … 

bleibt besser als:

sudo … 

Aber mein Hinweis hat ja eben zum Inhalt, dass

sudo -H … 

eben nicht alle Probleme löst, und erst recht nicht bei GUI-Programmen.

kB schrieb:

Das Problem bei der Verwendung von

sudo -H 

ist, dass das Arbeitsverzeichnis nicht gesetzt wird, sondern nur die Umgebungsvariable HOME.

Stimmt. Allerdings scheint das auch der Standard zu sein:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

$ sudo env | fgrep -w HOME
HOME=/root
$ sudo -H env | fgrep -w HOME
HOME=/root
$ sudo -i env | fgrep -w HOME
HOME=/root
$ sudo pwd
/home/user
$ sudo -H pwd
/home/user
$ sudo -i pwd
/root

Die Manpage von sudo sagt, dass es von den Sicherheitsregeln abhängt, ob HOME auch schon per default gesetzt wird.

Es ist sogar gar kein Arbeitsverzeichnis gesetzt.

Das geht nicht. Jeder Prozess hat ein Arbeitsverzeichnis. Wenn es nicht explizit von gesetzt wird, wir das vom Elternprozess geerbt.

Wenn jetzt eine Datei geschrieben werden soll und dabei kein absoluter Pfad verwendet wird, ist das Ergebnis unvorhersagbar.

Das hängt wesentlich davon ab, wie die Programme das Home-Verzeichnis ermitteln. Jedes halbwegs ordentliche Programm würde dafür nicht $HOME sondern einen robusteren Ansatz nutzen. (Beispiel).

Hallo,

AFAIK kommt der Hinweis im Wiki (stammt ja ursprünglich aus dem sudo Artikel) aus den Erfahrungen im Support. Sprich das "irgendwie irgendwo" eine Datei mit falschen Rechten und / oder an falscher Stelle geschrieben wurde, was eben Probleme macht. Wie im Beispiel von kB erklärt.

Ich persönlich hatte das Problem noch nie - da ich aber seit je her eine "Vanilla Ubuntu" benutzen mit der OOTB Konfig, bin ich da auch nicht so das Experte.

Aber das Problem war / ist ja scheinbar ein anderes. Was auch immer es ist / war, der TE möchte sich ja nicht mehr dazu äußeren.

Gruß, noisefloor

*von mir gelöscht*

Da stand nur Spielerei am Abend zum Thema sudo.

rklm schrieb:

[…]

Es ist sogar gar kein Arbeitsverzeichnis gesetzt.

Das geht nicht. Jeder Prozess hat ein Arbeitsverzeichnis.

Ich habe mich ungenau ausgedrückt. Ich wollte betonen, dass sudo -H … die Umgebungsvariable PWD nicht setzt. Damit haben alle Programme, welche diese verwenden wollen, schon einmal ein Problem und machen dann vielleicht etwas, was der Programmierer nicht vorher gesehen hat und der Benutzer nicht will. Das Arbeitsverzeichnis selbst ist natürlich gesetzt, allerdings auf den alten Wert, also z.B. auf das Benutzerverzeichnis des aufrufenden Benutzers:

$ pwd
/home/klaus
$ sudo -H pwd
/home/klaus

Genau das wollte der Benutzer eigentlich mit der Option -H verhindern. Dumm nur, dass diese Option genau das nicht macht und lt. Dokumentation auch gar nicht machen soll.