root braucht sudo

[Simaryp]

Ich bin gerade beim Erstellen von ein paar Skripten und stolpere gerade über eine verwirrende Sache.
Da die Skripte später per systemd ausgeführt werden sollen und das ja mit root Rechten geschieht, wollte ich mal schauen, wie ich die Befehle genau aufschreiben muss. Daher habe ich mich mit su root als root angemeldet. Zu meiner Überraschung muss ich auch als Nutzer root nun sudo eingeben, ansonsten funktioniert zum Beispiel hdparm oder hddtemp nicht.

[KP97]

su und su - haben unterschiedliche Pfade, das Thema wurde hier aber schon ca. 1253 mal besprochen...

Da die Skripte später per systemd ausgeführt werden sollen und das ja mit root Rechten geschieht

Nicht unbedingt, wenn systemd einen service als user ausführen soll, muß die Datei nach
/etc/systemd/user eingestellt und dort auch enabled werden.

[MSfree]

Zu meiner Überraschung muss ich auch als Nutzer root nun sudo eingeben, ansonsten funktioniert zum Beispiel hdparm oder hddtemp nicht.

Unsinn, sudo ist da absolut nicht nötig. Was aber nötig ist, ist die vollständige Pfadangabe eines Befehls, was vor allem in Scripten sowieso ein muß sein sollte.

hdparm befindet sich übrigens im Verzeichnis /sbin.

[Simaryp]

Sorry, wenn es ne dumme frage war. Ich kannte das bisher so noch nicht.
Mit /sbin/hdparm geht es danke.

Ist das nur so, wenn ich mich mit su als root anmelde oder auch wenn das Skript als root ausgeführt wird? Oder wenn ich mich direkt als root anmelde?

[MSfree]

Ist das nur so, wenn ich mich mit su als root anmelde oder auch wenn das Skript als root ausgeführt wird? Oder wenn ich mich direkt als root anmelde?

Das Geheimnis steckt in der Umgebungsvariable PATH, die du dir mit

Code: Alles auswählen

echo $PATH

auf der Kommandozeie ansehen kannst.

Mit su fehlen die Verzeichnisse /sbin und /usr/sbin, so daß Aufrufe von Programmen, die sich in den beiden Verzeichnissen befinden mit "nicht gefunden" quittiert werden.

Mit su - (man beachte das Minus am Ende) bekommt man /sbin und /usr/sbin gesetzt.

Als root-Login sind /sbin und /usr/sbin ebenfalls gesetzt.

Shellskripte, die von systemd oder cron gestartet werden, haben in der Regel gar keinen PATH gesetzt.

Wenn man sicher gehen will, sollte man in Skripten also immer den vollen Pfad eintragen.

[fischig]

Welchen Sinn macht eigentlich noch ein nacktes su (ohne Minus, also ohne den Pfad für root)? Mal abgesehen davon, dass man's wieder hinbiegen kann, aber wenn's keinen Sinn mehr gibt, dann wäre es vielleicht besser, diese Variante ganz einzustampfen, statt noch in zehn Jahren mit der entsprechenden Frage konfrontiert zu werden.

[KP97]

... dann wäre es vielleicht besser, diese Variante ganz einzustampfen, statt noch in zehn Jahren mit der entsprechenden Frage konfrontiert zu werden.

Tja, diese Variante ist ja erst mit Buster eingeführt worden, in Anpassung an andere Distributionen von z.B. RedHat bzw. Suse.
So schnell wird das also nicht wieder verschwinden, in meinem Sid habe ich das schon vor längerer Zeit geändert.
Wie es geht, wurde hier auch schon sehr oft beschrieben...

[fischig]

Tja, diese Variante ist ja erst mit Buster eingeführt worden [...] So schnell wird das also nicht wieder verschwinden

Ich fühle mich missverstanden. Ich möchte nicht die konkurrenzlos sinnvolle neue Variante abgeschafft wissen. Das hieße ja, dass ich hoffnungslos rückständig wäre, im Grunde ein todeswürdiges Verbrechen an der Gemeinschaft. Ich frage mich, welches Lebensrecht die absolut indiskutable alte Veriante noch hat - nicht zuletzt deinem Blutdruck zuliebe.

[MSfree]

Ich frage mich, welches Lebensrecht die absolut indiskutable alte Veriante noch hat - nicht zuletzt deinem Blutdruck zuliebe.

Ich befürchte, es ist sehr müssig darüber zu diskutieren. Die Änderungen wurden vor einigen Jahren vollzogen.

[fischig]

Nochmal: es geht mir gar nicht um die Änderung an sich, sondern um deren halbherzige Implementierung. Wobei ich nicht mal weiß, ob sie denn halbherzig ist. Danach hatte ich weiter oben indirekt gefragt. Aber bisher hat meines Wissens noch niemand versucht, zu zeigen, warum die Fortexistenz von nacktem su in Debian Sinn macht. Mir fällt keiner ein. Und ich weiß auch nicht, wies andernorts aussieht. Ich benutze nur Debian. Aber viele hier regen sich auf, sind zumindest genervt über Leute, die es auch nach Jahren noch nicht mitbekommen haben. Mich verwundert das eigentlich nicht. su ist ein essenteilles Kommando eines Debian-Systems. Es ist ja so selbsterklärend, dass, wenn su nicht funktioniert, dann eben

Code: Alles auswählen

su -

funktionieren muss. Ich behaupte, kein deutschsprachiger Mensch, der Debian seit langer Zeit anwendet, aber auch nur anwendet, hier nicht sehr intensiv mit liest, oder tief am System bastelt, kriegt das "intuitiv" mit. Was er auch nicht müsste, wenn ihm ein nacktes su als irgendwie unvollständig auf die Füße fallen würde. Tut's aber nicht. Warum's trotzdem nicht funktioniert und dass das an $PATH liegt, erfährt er nur, wenn er hier fragt. Oder aber ihn beschleicht die Vermutung: "root braucht sudo" - jetzt nicht nur in *buntu, sondern auch in Debian.

Das ist meines Erachtens verbesserungsbedürftig.

[TRex]

Hier ist der Bugreport: https://bugs.debian.org/cgi-bin/bugrepo ... bug=907194

[fischig]

Danke für die Information!

[whisper]

su ist ein essenteilles Kommando eines Debian-Systems.

Nein su ist ein unix Kommando, das so für Linux implementiert wurde.
Ich habe vor >25 Jahren Unix Kurse besucht, dort wurde schon immer su - benutzt und auf den Unterschied zu su hingewiesen.
Ganz im Gegenteil ich empfand die Nachlässigkeit vom alten Debianverhalten komisch, weil ich es gewohnt war und bin su - zu benutzen.

[MSfree]

Ich habe vor >25 Jahren Unix Kurse besucht, dort wurde schon immer su - benutzt und auf den Unterschied zu su hingewiesen.

Nunja, Unixkurse habe ich vor 25 Jahren zwar nicht besucht, aber damals gab es auch noch kein /sbin und /usr/sbin, bzw. wurde PATH nicht durch den Aufruf ohne Minus verkrüppelt. Der Unterschied ob mit oder ohne Minus war also damals irrelevant, mal abgesene davon, daß einen su - auf das Homeverzeichnis von root bringt, während su (ohne Minus) im aufrufenden Verzeichnis bleibt.

Ich finde jedenfalls das Verhalten von su - eher kontraproduktiv. Ich will in der Regel ja gar nicht ins /root-Verzeichnis wechseln sondern z.B. Dateibesitz und/oder -rechte im aktuellen Verzeichnis ändern.

[whisper]

damals gab es auch noch kein /sbin und /usr/sbin, bzw. wurde PATH nicht durch den Aufruf ohne Minus verkrüppelt. Der Unterschied ob mit oder ohne Minus war also damals irrelevant, mal abgesene davon, daß einen su - auf das Homeverzeichnis von root bringt, während su (ohne Minus) im aufrufenden Verzeichnis bleibt.

Ich finde jedenfalls das Verhalten von su - eher kontraproduktiv. Ich will in der Regel ja gar nicht ins /root-Verzeichnis wechseln sondern z.B. Dateibesitz und/oder -rechte im aktuellen Verzeichnis ändern.

Nur unter Linux gibt es /root.
Das wurde wahrscheinlich gemacht, um Neueinsteiger vor versehentlichen rm -rf * zu schützen
Dass es /sbin und /usr/sbin nicht gab, glaube ich nicht, kann es ohne Recherche aber auch nicht widerlegen.
Tatsache ist genau die Sache mit dem PATH ist ja extra so gewollt. Zum Beispiel hat root kein . also den aktuellen Pfad im PATH. Dies bleicbt aber erhalten, wenn man vom normal User mit su die root Rechte annimmt. ein ls im aktuellen verzeichnis wird dann also ggfs. ./ls ausführen, wenn vorhanden..
Nicht vergessen sollte man auch die vielfältigen Möglichkeiten von su. So z.B. kann man mit su - monitoring zum user monitoring werden um nach anpassen von Konfigurationen keine Gedanken an die user/gruppen Rechten zu verschwenden... oder z.B. su - -s /bin/bash www-data
als user www-data arbeiten, obwohl www-data gar keine Login shell hat.
Aber gut, bin ja jetzt wieder still.

[fischig]

Nein, su ist ein unix Kommando

Das dürfte wohl richtig sein, nur ist es unerheblich für die aktuelle Diskussion.

su (mit oder ohne Parameter) ist (oder war?) AUCH für die Bedienung eines Debian-Systems essentiell. Mir geht's nur darum: Wenn schon

Code: Alles auswählen

su -

wozu dann noch

Code: Alles auswählen

su

? Auch deine Beispiele gehen genau darauf nicht ein, soweit ich sehe. (Bei der "ob"-Frage bin ich eher bei MSfree.)

[whisper]

su (mit oder ohne Parameter) ist (oder war?) AUCH für die Bedienung eines Debian-Systems essentiell. Mir geht's nur darum: Wenn schon

Code: Alles auswählen

su -

wozu dann noch

Code: Alles auswählen

su

? Auch deine Beispiele gehen genau darauf nicht ein, soweit ich sehe. (Bei der "ob"-Frage bin ich eher bei MSfree.)

Konkretes Beispiel: Ich will /etc/fstab bearbeiten, warum auch immer; fstab ist nur als root editierbar.
bed@tuxedo:~/Downloads$ su
Passwort:
root@tuxedo:/home/bed/Downloads# gedit /etc/fstab

Jetzt kann ich mit einem grafischen Editor mit root Rechten die fstab bearbeiten, Ohne die Loginshell von root zu verwenden.
VErsuche ich das mit su - scheitert das.

[MSfree]

Nur unter Linux gibt es /root.
Das wurde wahrscheinlich gemacht, um Neueinsteiger vor versehentlichen rm -rf * zu schützen

Unter verschiedenendamaligen Unixen hatte root sein Home natürlich nicht unbedingt unter /root, unter IRIX war, wenn ich das noch richtig in Erinnerung habe, /usr/people/root. Aber ein Schutz vor rm -rf * bot und bietet das ja nun nicht wirklich. Wenn der Benutzer mit su - im Home von root gelandet ist und dort versehentlich rm -rf * aufgerufen hat, war halt alles, was root gehörte, weg. OK, das ist ggfls. weniger tragisch, weil dort die Benutzer (mit root-Rechten) hoffentlich keine Datenlager angelegt haben, aber Schutz ist das nicht.

Dass es /sbin und /usr/sbin nicht gab, glaube ich nicht, kann es ohne Recherche aber auch nicht widerlegen.

Die ersten Unixe, mit denen ich vor 30 Jahren zu tun hatte, hatten es jedenfalls nicht, das waren allerdings System-V Unixe. Die BSD-Derivate waren da noch deutliche unterschiedlich aufgebaut. AFAIK war SunOS 4 noch BSD-basiert, während Solaris 2.4 schon SysV angenähert war. Und ich meine Solaris 2.4 war das erste Unix, bei dem ich /sbin und /usr/sbin gesehen hatte. Aber OK, das könnte dann aber zeimlich genau in die Zeit vor 25 Jahren fallen.

Tatsache ist aber, das PATH nur eine Komfortfunktion ist und man das gesamte System auch ohne PATH administrieren und zerstören kann. Daher ist sowieso immer besondere Vorsicht geboten, wenn man sich mit root-Rechten im System bewegt.

Kleine Anekdote:
Ein ehemaliger Kollege wollte nur ein paar Dateien löschen, die mit einem Punkt angefangan haben. Sein Befehl war rm -rf .*
Nach ein paar Minuten kam die Frage, warum ein kleiner rm so lange dauert. Ein paar Sekunden später war die Kiste dann abgestürzt und bootete ncht mehr. Die nächsten zwei Tage waren dann mit Neuisntallation der Maschine vergeudet.

[fischig]

Konkretes Beispiel: Ich will /etc/fstab bearbeiten, warum auch immer; fstab ist nur als root editierbar.
bed@tuxedo:~/Downloads$ su
Passwort:
root@tuxedo:/home/bed/Downloads# gedit /etc/fstab

Jetzt kann ich mit einem grafischen Editor mit root Rechten die fstab bearbeiten, Ohne die Loginshell von root zu verwenden.
VErsuche ich das mit su - scheitert das.

Sitmmt so, habe ich nachvollzogen.

Macht mich leider eher noch unsicherer, was ich von dieser Umstellung (su vs. su -) eigentlich halten soll.

Oder anders rum: Welchen Sinn macht es, dass der User mit su /etc/fstab grafisch bearbeiten darf, aber mit su - nicht?

[TRex]

Es mag dir sinnvoll erscheinen, das so zu betrachten, aber würdest du su nicht kennen, dann würdest du dich fragen, wie du dein Problem lösen sollst statt warum der (gelernte) Weg nicht (mehr) funktioniert. Es war eine Eigenart von debian, das so zu lösen, und es gibt viele valide Argumente, diese Eigenart abzulösen. Wenn du triftige Gründe dagegen siehst, solltest du einen Bug melden bzw. dich dem Bugreport anschließen. Hier wird das nicht geändert, hier wird nur der Eigenart hinterhergeweint.

[TomL]

Oder anders rum: Welchen Sinn macht es, dass der User mit su /etc/fstab grafisch bearbeiten darf, aber mit su - nicht?

Ich glaube nicht, dass ein Sinn hinter diesem Effekt steht... und das ist es, wie ich das einschätze, das ist imho nur ein Effekt aufgrund des Enviroments im Zusammenhang mit der Rechteverwaltung... u.a. eben auch für den Zugriff auf den laufenden XServer.

Code: Alles auswählen

thomas@d10-xfce:~$ su -
Passwort: 
root@d10-xfce:~# echo $USER
root

root@d10-xfce:~# exit
Abgemeldet

thomas@d10-xfce:~$ su
Passwort: 
root@d10-xfce:/home/thomas# echo $USER
thomas

[fischig]

das ist imho nur ein Effekt aufgrund des Enviroments im Zusammenhang mit der Rechteverwaltung... u.a. eben auch für den Zugriff auf den laufenden XServer.

Das ist mir schon klar. Und du siehst - wenn ich dich recht verstehe - auch keinen Sinn darin.

Jetzt wollt' ich doch mal 'ne Lanze brechen für modernes Debian und nu isses anscheinend schon wieder Essig!

[MSfree]

Welchen Sinn macht es, dass der User mit su /etc/fstab grafisch bearbeiten darf, aber mit su - nicht?

Man darf in beiden Fällen /etc/fstab grafisch bearbeiten.
Der Unterschied, ob root auf den X-Server zugreifen darf oder nicht, liegt nur in der Umgebungsvariable XAUTHORITY, die in einem Fall automatisch vom User übernommen wird und im anderen Fall gelöscht wird. Setzt man diese Umgebungsvariabel als root nach su - manuell, kann man auch wieder einen graphischen Editor aufrufen.

Da das manuelle Setzen der Umgebungsvariable keine verbotene Handlung darstellt, ist auch das Editieren nicht verboten. Somit stellen auch die Umgebungsvariablen keinen Systemschutz dar.

Wie gesagt, Umgebungsvariablen dienen hauptsächlich dem Komfort aber nie, um bestimmte Aktionen zu verbieten.