[erledigt] su oder sudo - Wie herausfinden, welches geht?

[MartinV]

Ich schreibe ein Skript mit einer Paßwortabfrage.
Wie stelle ich fest, ob ich su oder sudo nehmen sollte?

Derzeit habe ich su als default, und per switch --sudo kann man auf eine sudo-Abfrage umschalten. Das finde ich unelegant.

Eine andere Möglichkeit wäre, per "lsb_release -is" den Namen der Distribution herauszufinden und eine lange Liste aller sudo-Distris anzulegen und darauf zu prüfen. (In erster Linie wohl Ubuntu samt aller Ableger). Auch nicht sehr elegant, zumal viele kleine Distris entstehen und vergehen, und die Liste nie aktuell und vollständig sein kann.

Auf Mitgliedschaft in Gruppe "sudo" prüfen ist einfach, aber unzuverlässig - sudo wird ja manchmal tatsächlich so eigesetzt, wie es mal gedacht war, also nur für einzeln definierte Kommandos, nicht pauschal für alles. /etc/sudoers parsen geht nur, wenn ich schon root-Rechte habe, fällt also auch aus.

Eine denkbare (und die eleganteste) Möglichkeit wäre es zu prüfen, ob root ein Paßwort hat - aber wie? /etc/passwd hilft mir nicht weiter.

Habt ihr eine gute Idee?

[TomL]

Habt ihr eine gute Idee?

Ja, beides nicht zu verwenden, sondern stattdessen "pkexec"... das funktioniert definitiv bei Debian, Fedora, Ubuntu, Mint... und bei allen anderen vermutlich auch, die ebenfalls systemd verwenden.

[KP97]

Vielleicht hilft Dir dieser Beitrag weiter, ich selbst kenne das aber nicht:
viewtopic.php?f=27&t=166152

[jeff84]

Du hättest die Möglichkeit zu checken, ob sudo installiert ist und dann via

Code: Alles auswählen

sudo -l

checken, was du per sudo alles darfst.

[MartinV]

Danke für Eure Antworten!

@TomL: pkexec habe ich gerade mal durchgetestet, und ich dachte erst, tatsächlich, damit geht es! Leider habe ich etwas seltsames festgestellt und dabei eine Ausnahme gefunden:
root-Rechte mit pkexec bekomme ich mit dem (eigentlich!) unprivilegierten User-Paßwort . Das root-Paßwort wird nicht akzeptiert.
Aber auch das geht nur für den "ersten" Benutzer des Systems (uid 1000). Andere Benutzer (uid 1002) können mit pkexec keine root-Rechte bekommen, mit keinem der Paßwörter von uid 0, 1000 oder 1002.
Schade, das hätte es sein können.

@KP97: Danke für den Link, runuser habe ich mir auch mal angeschaut. Es scheint jedoch nur dazu geeignet zu sein, von root zu anderen Benutzern zu wechseln, nicht aber umgekehrt. runuser läßt sich nur als root aufrufen.

@jeff84: sudo -l ist interessant, danke für den Hinweis! Das schaue ich mir mal genauer an, damit könnte ich es hinbekommen.

[TomL]

Das ist fast nicht vorstellbar.... und verstehen tu ich es nicht. Wenn Du mit

Code: Alles auswählen

su

zum root-Account wechselst und das gleiche Password in einem anderen Terminal mit einem beliebigen User-Account nach Eingabe dieses Befehls

Code: Alles auswählen

pkexec nano

oder

Code: Alles auswählen

pkexec bash

verwendest, dann klappt das nicht? Welche Fehlermeldung kommt dann?

[heisenberg]

Du möchtest also den Benutzer auffordern sein Passwort einzugeben(für den Fall dass der user sudo-root-rechte hat), oder das Passwort von root(wenn denn eines gesetzt sein sollte)?

[MartinV]

@TomL: Jetzt habe ich Dich nicht ganz verstanden ...

Mit su kann ich nur mit root-Paßwort zum root-Account wechseln.
Mit pkexec kann ich nur mit User-Paßwort (uid 1000) zum root-Account wechseln.
Und meine Aussage von oben muß ich korrigieren:
User mit uid ungleich 1000, z.B. uid=1002, können nur mit dem User-Paßwort von uid 1000 zum root-Account wechseln.

Andere Paßworteingaben werden gemeldet!

Und andere User um das Paßwort von User 1000 zu bitten, finde ich etwas seltsam.

@heisenberg: ja, ich will im Skript ein paar Befehle ausführen, die root-Rechte benötigen. Dafür brauche ich einmal das Paßwort, je nach Distri entweder für su oder für sudo.

[heisenberg]

Ein Gedanke dazu:

Wer wenige Kenntnisse hat, der wird in seinem eigenen Interesse eine Mainstream-Distri haben. Wer etwas Extravagantes hat, bei dem kann man etwas mehr Wissen voraussetzen. ( Und wer eine Fortgeschrittenen-Distri als Anfänger benutzt, der hat Pech gehabt, bzw. muss das harte Brot kauen, was er sich selbst vorgesetzt hat. )

Für die Mainstream-Distris kann man Fallunterscheidungen einbauen. Dem Rest kann man zumuten, dass Sie entweder das Skript selbst als root ausführen sollen oder auf Verdacht testweise zwei Abfragen beantworten sollen.

[brummer]

Ich schreibe ein Skript mit einer Paßwortabfrage.
Wie stelle ich fest, ob ich su oder sudo nehmen sollte?

Derzeit habe ich su als default, und per switch --sudo kann man auf eine sudo-Abfrage umschalten. Das finde ich unelegant.

Darf man fragen warum? Ich meine nimm einfach su und fertig.
Ich mach so was ganz pragmatisch, ohne fragen, klar und deutlich, mit:

Code: Alles auswählen

 # Make sure only root can run our script
if [ "$(id -u)" != "0" ]; then
   echo "This installer must be run as root" 1>&2
   exit 1
fi

[heisenberg]

Darf man fragen warum? Ich meine nimm einfach su und fertig.

Weil su zu root es erfordert, dass ein root-Passwort gesetzt ist. Das ist z. B. bei Ubuntu und auch einigen Derivaten davon nicht der Fall. Martin möchte vermutlich, dass sein Script bequem zu nutzen ist. Deswegen sucht er nach zusätzlichen Möglichkeiten.

[Meillo]

Ich mach so was ganz pragmatisch, ohne fragen, klar und deutlich, mit:

Code: Alles auswählen

 # Make sure only root can run our script
if [ "$(id -u)" != "0" ]; then
   echo "This installer must be run as root" 1>&2
   exit 1
fi

Scripte, die interaktiv fragen sind sowieso doof, darum wuerde ich auch in diese Richtung tendieren. (Das ist auch der uebliche Ansatz.)

[scientific]

Aber hat pkexec nicht den Vorteil, dass es je na verfügbarer Oberfläche entscheidet, ob eine Abfrage im Terminal oder über ein GUI macht?

Wenn du bei pkexec genau schaust, wird dann bei UID 1002 auch der Username von 1000 angezeigt?
Dann hat das wohl mit einer Gruppenzugehörigkeit zu tun.

Man kann sich auch eigene Regeln mit Berechtigungen schreiben, für eigene Programme. Aber da bin ich leider noch nicht durchgestiegen, wie das funktioniert.

Ev. kannst du auch mit capabilities arbeiten.

Für welche Befehle benötigst du überhaupt root in deinem Skript?

[TomL]

Mit su kann ich nur mit root-Paßwort zum root-Account wechseln.
Mit pkexec kann ich nur mit User-Paßwort (uid 1000) zum root-Account wechseln.

Nein, das ist falsch. Mit "su" und dem root-Password wechselst Du im Terminal in den root-Account. Mit "pkexec bash" und ebenfalls dem root-Password bekommst Du eine root-shell. In beiden Fällen ist "root" der aktuelle User. Beides hat NIX mit dem User 1000 oder sonst wem zu tun. Beide Befehle beanspruchen direkt den root-Account und verlangen das root-Password. Welcher User den pkexec-Befehl absetzt ist irrelevant... entweder er hat das root-Password oder er ist über eine Rule berechtigt, und der Job läuft danach immer unter der root-ID. Punkt!

Sofern nicht explizit der --user-Parameter angegeben wurde, führt Pkexec also immer alle Befehle als root unter der ID von root aus. Pkexec kann Befehle mit --user auch als "anderer User" ausführen, aber dann hat der Prozess auch nur die schmalen Rechte von "anderer User".... und das willst Du ja nicht, Du brauchst ja root-Rechte. Selbst wenn der User 1000 einen Pkexec-Befehl und Eingabe des root-Passworts absetzt, läuft dieser Prozess unter der ID von root und mit den Rechten von root, so als hätte "root" diesen Prozess selber gestartet.

Und jetzt die Besonderheit... wenn Du dem User ermöglichen willst, ein Programm mit root-Rechten zu starten, aber sie sollen dafür entweder ihr eigenes Passwort oder für diesen speziellen Prozess vielleicht gar kein Passwort eintragen, dann ist eine Polkit-Rule erforderlich. Entsprechend dieser Rule fragt pkexec entweder nach dem root-Password, nach dem User-Password oder nach nix.

BTW, ich würde sowieso auch das empfehlen, was andere schon gesagt haben.... entweder den ganzen Job via Polkiit-Rule als root laufen lassen, oder einfach ablehnen, wenn der aktuelle Account nicht root ist.

Aber hat pkexec nicht den Vorteil, dass es je na verfügbarer Oberfläche entscheidet, ob eine Abfrage im Terminal oder über ein GUI macht?

Das funktioniert bei mir verblüffenderweise unter Stretch nicht mehr....die Text-Abfrage im Terminal failed bei jeder Passwordeingabe ... keine Ahnung warum... keine Ahnung, ob das ein Bug ist. Bei mir funktioniert nur der GUI-Dialog. Ich bemerke das nur nicht, weil ich eben für die Jobs alles über Rules geregelt habe und die Password-Abfrage nicht kommt. Aber merkwürdig ist das schon.

[MartinV]

Darf man fragen warum? Ich meine nimm einfach su und fertig.

Weil su zu root es erfordert, dass ein root-Passwort gesetzt ist. Das ist z. B. bei Ubuntu und auch einigen Derivaten davon nicht der Fall. Martin möchte vermutlich, dass sein Script bequem zu nutzen ist. Deswegen sucht er nach zusätzlichen Möglichkeiten.

Genau das!

Darf man fragen warum? Ich meine nimm einfach su und fertig.

Für welche Befehle benötigst du überhaupt root in deinem Skript?

Mein Skript (x11docker) muß einige Befehle als unprivilegierter User starten (X server wie z. B. Xephyr), und einige als root (Aufrufe von docker).
Bisher habe ich es mit einer Paßwortabfrage in einem Terminalfenster gelöst. Aktuell überarbeite ich Paßwortabfrage und User-Verwaltung, und möchte sie bequemer und flexibler gestalten, und verwende, falls vorhanden, gksu bzw. gksudo.

Aber hat pkexec nicht den Vorteil, dass es je na verfügbarer Oberfläche entscheidet, ob eine Abfrage im Terminal oder über ein GUI macht?

Ja, und das ist klasse. (Es fehlt nur Wayland-Unterstützung ohne X). Wäre da nicht das seltsame Verhalten, daß nur der User mit uid 1000 mit unprivilegiertem Paßwort zu root werden kann. (Ich gehe mal davon aus, daß das eine von debian so eingerichtete Konfiguration ist).

Wenn du bei pkexec genau schaust, wird dann bei UID 1002 auch der Username von 1000 angezeigt?

Ja.

Dann hat das wohl mit einer Gruppenzugehörigkeit zu tun.

Hm. User 1000 hat gid 1000 und noch ein paar Gruppen. User 1002 hat nur gid 1002. Keine gemeinsamen Gruppen. User 1000 ist in der Gruppe sudo, aber ist in /etc/sudoers auskommentiert.

Man kann sich auch eigene Regeln mit Berechtigungen schreiben, für eigene Programme. Aber da bin ich leider noch nicht durchgestiegen, wie das funktioniert.

Das will ich aus Grüden der Bequemlichkeit nicht machen - das Skript soll ohne Vorarbeit des Users einfach funktionieren.

Mit "pkexec bash" und ebenfalls dem root-Password bekommst Du eine root-shell.

Bei mir ist es anders!
Vielleicht liegt es an der Mitgliedschaft in der sudo-Gruppe, auch wenn es keinen Eintrag in /etc/sudoers gibt. Das kann ich gleich noch einmal testen.
"pkexec bash" mit root-Paßwort:

Code: Alles auswählen

$ pkexec bash
Error executing command as another user: Not authorized

This incident has been reported.

Das funktioniert bei mir verblüffenderweise unter Stretch nicht mehr....die Text-Abfrage im Terminal failed bei jeder Passwordeingabe

Das wiederum geht bei mir tadellos ...

Ich habe "sudo -l" getestet und festgestellt, daß ich mit "sudo -l docker" zuverlässig festellen kann, ob der Befehl "docker" mit sudo geht, oder ob ich su brauche. Damit ist die Titelfrage "su oder sudo" gut gelöst.
Von pkexec sehe ich (leider!) ab, wegen der seltsamen Eigenheiten.

Danke euch allen! Soweit markiere ich den Thread als gelöst. Die Fragen/Unklarheiten rund um pkexec, das ja su/sudo/gksu/gksudo langfristig ablösen soll, bleiben natürlich interessant.

[scientific]

Dann füge mal den User 1002 zur Gruppe sudo und probiers mit pekexec nochmal...

[MartinV]

Dann füge mal den User 1002 zur Gruppe sudo und probiers mit pekexec nochmal...

Jetzt fragt er User 1002 nach dem Paßwort von 1002!

Dann habe ich User 1000 aus Gruppe sudo herausgeworfen. Jetzt wird User 1000 nach dem Paßwort von User 1002 gefragt.

Schmeiße ich beide aus Gruppe sudo heraus, werde ich nach dem Paßwort von root gefragt, wie TomL es beschrieben hat.

In /etc/sudoers ist nur root eingetragen.

Anscheinend hat pkexec eine Paßwort-Prioritätenliste, in der Mitglieder der Gruppe sudo vor root bevorzugt werden. /etc/sudoers wird dabei ignoriert. Das hebelt den Sinn von sudo (für einzeln privilegierte Kommandos) restlos aus und ist in meinen Augen eine GROSSE Sicherheitslücke. Alle Mitglieder der Gruppe sudo haben uneingeschränkten root-Zugriff mittels pkexec, völlig egal, was in /etc/sudoers steht. !!eins11!!!!

[TomL]

Alle Mitglieder der Gruppe sudo haben uneingeschränlten root-Zugriff mittels pkexec, völlig egal, was in /etc/sudoers steht.

Genau das habe ich schon vor 1 Jahr oder so gesagt... ich halte "sudo" für einen exploit. Und genau darauf hab ich schon oft hingewiesen... kein Schwein kennt die Wechselwirkungen mit dem Polkit. "sudo" zu deinstallieren ist heute immer das erste, was ich bei einem frischen System tue. Vor allem, weil man den Befehl "sudo" mit nem ganz einfachen Bash-Alias ersetzen kann, was für manuelle einzelaktionen im Terminal allemal ausreicht:

Code: Alles auswählen

alias sudo="pkexec $@"

Mit dem Default-Password-Keep besteht die nächste große Lücke.... das ist das Einfallstor für so Kisten wie den Bundestrojaner. Egal, jeder wie er mag.....

[MartinV]

"sudo" zu deinstallieren ist heute immer das erste, was ich bei einem frischen System tue.

Das reicht nicht!
Ich habe sudo jetzt deinstalliert, User 1000 der Gruppe sudo hinzugefügt, und habe als User 1000 mit Paßwort von User 1000 unbegrenzten root-Zugriff mit pkexec.
Gruppenmitgliedschaft in Gruppe sudo reicht, um mit pkexec root zu werden. Völlig unabhängig vom Paket sudo, und völlig egal, was in /etc/sudoers steht.

[Meillo]

Alle Mitglieder der Gruppe sudo haben uneingeschränlten root-Zugriff mittels pkexec, völlig egal, was in /etc/sudoers steht.

Genau das habe ich schon vor 1 Jahr oder so gesagt... ich halte "sudo" für einen exploit. Und genau darauf hab ich schon oft hingewiesen... kein Schwein kennt die Wechselwirkungen mit dem Polkit. "sudo" zu deinstallieren ist heute immer das erste, was ich bei einem frischen System tue.

Das Problem, das du hier beschreibst, ist doch aber die komplexe Wechselwirkung zwischen Polkit und sudo. Dagegen kann man grundsaetzlich auf zwei Arten angehen: Entweder man entfernt die eine oder die andere Komponente. Du setzt voraus, dass es (natuerlich) besser ist die eine der beiden Komponenten zu entfernen. Verstehe ich das richtig?

Da Polkit (2007) nach sudo (1980) entstanden ist, tendiere ich dazu Polkit fuer die Probleme verantwortlich zu machen. Oder was uebersehe ich?

[TomL]

Da Polkit (2007) nach sudo (1980) entstanden ist, tendiere ich dazu Polkit fuer die Probleme verantwortlich zu machen.

Weil sudo um 1980 entstanden ist, also zu einer Zeit, als kein Mensch eine Vorstellung von GUI-Enduser/Multiuser-Desktop-PCs hatte und dementsprechend eine dieser Zeit angemessene RZ-Zielsetzung hatte, und weil sudo wegen dieser prähistorischen Zielsetzung eine Ausgestaltung hat, die faktisch völlig untauglich und absolut unzureichend für moderne grafische Betriebssysteme ist, tendiere ich dazu, sudo in den Orkus zu verbannen.

Wie unzureichend "sudo" für moderne grafische OS ist, beweist die Existenz (und wohl auch Notwendigkeit) solcher anzutackernder Prothesen wie "ksudo, kdesudo, kdesu, gksudo, gksu". Das Polkit braucht das alles nicht. Es kommt sowohl mit GUI- als auch Textumgebungen klar. Und das Polkit ist im Gegensatz zu "sudo" nicht per Default ein 15-Min-Password-Keep-Exploit, womit sich wirklich jede Anwendung im Vorbeimarsch Root-Rechte verschaffen kann.

j.m.2.c.

PS
Ich klink mich hier aus der sudo-Diskussion aus... das Thema ist wahrlich schon genug belabert worden. Und neues gibts eh nix zu sagen. Jeder soll tun, was er mag...... ich mag halt kein sudo..... damit isses genug für mich.

[Meillo]

Danke fuer die Darstellung deiner Sichtweise. Jetzt habe ich sie besser verstanden.

[MartinV]

Ich habe einen Bugreport für policykit-1 geschrieben:
#869922 policykit-1: members of group sudo become root with pkexec while ignoring /etc/sudoers

[scientific]

Die Antwort scheint sehr eindeutig.

Mitglieder der Gruppe sudo sollen root werden können.

Wenn du beim Installieren den root-Account aktivierst, sollte UID 1000 nicht der Gruppe sudo angehören.

Gibt es keinen root-Account, muss ja irgendein Account rootrechte bekommen können. Wie willst du sonst das System administrieren?

[TomL]

Die Antwort scheint sehr eindeutig.
Mitglieder der Gruppe sudo sollen root werden können.
Wenn du beim Installieren den root-Account aktivierst, sollte UID 1000 nicht der Gruppe sudo angehören.
Gibt es keinen root-Account, muss ja irgendein Account rootrechte bekommen können. Wie willst du sonst das System administrieren?

Vielleicht hat er ja auch beides gemacht... root ein Password vergeben und irgendwelche User gleichzeitig in der Gruppe sudo eingetragen... gemäß dem Motto "doppelt hält besser". Keine Ahnung wie sich das verhält.... der Debian-Installer macht ja eigentlich nur eins von beiden beim Install. Ich denke, mit root-Password sollte die Gruppe "sudo" gar nicht bestückt werden, oder dem traditionellen Gedanken folgend nur für explizite Anwendungen in der sudoers berechtigt werden. Aber ob's jetzt hier und bei Default-Einstellungen zu Problemen kommen kann.... keine Ahnung..?... ich empfinde das aber auf mich bezogen jedenfall als Kontrollverlust... weil ich die Wechselwirkungen nicht mehr im Griff habe.