root braucht sudo

[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.