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

[MartinV]

Ich glaube, die Quelle des Problems ist nicht das Polkit, auch wenn das Polkit jetzt diesen Effekt zeigt. Das Problem liegt eher bei Debian, weil sich die Entwickler entschlossen haben, sogar bei Stretch immer noch ein Polkit einzusetzen, was schon bei Jessie alt war... und zwar immer noch die Version 0.105.
[...] Egal... das TTY-Problem besteht aktuell in Debian

Hmm... Ich habe mal gerade einen Test auf Fedora 25 gemacht. "pkexec --version" zeigt 0.113 und funktioniert auch nicht auf der Konsole, gleiche Fehlermeldung wie oben. Ebenso funktioniert es nicht auf anderen X Servern.

Allerdings versteh ich nicht,warum Du darauf bestehst, dass der User sein Password eingeben muss... denn Du wirst ihm ja wohl kein root-PWD geben.

Um docker zu starten, braucht der user root-Rechte. Das geht z.B. auf debian mit su und root-Paßwort, und z.B. auf Ubuntu mit sudo und User-Paßwort. Weder su noch sudo funktioniert von Haus aus auf beiden Systemen, nur entweder-oder.

Ich würde die betroffenen User explizit in eine Gruppe (nicht sudo!) eintragen und die Gruppe via Polkit ohne PWD-Abfrage berechtigen. Und alle User, die nicht in der Gruppe enthalten sind, würde ich gleich am Anfang des Scripts abschmettern, so dass erst gar keine PWD-Abfrage kommt, die einen Fehler produziert.

Mein Skript soll auf beliebigen Systemen laufen können. Für gewöhnlich hat der User ein Paßwort, um root-Rechte zu bekommen, entweder für su oder für sudo. (Irgendwelche Firmenarbeitsplätze mal ausgenommen).
Das System erst umzukonfigurieren, damit mein Skript starten kann, kann/will ich von beliebigen Usern nicht verlangen. Ich habe (für mich) den Anspruch, daß Programme "einfach funktionieren" sollen, ohne daß man erst etwas schrauben muß.

Es scheint keine allgemeingültige Lösung für eine Paßwortabfrage zu geben, um root-Rechte zu bekommen.
Ich gehe jetzt nach "Wahrscheinlichkeitsschätzung": Ist der User in Gruppe sudo, darf er wahrscheinlich "sudo docker" ausführen, und ich verwende im Skript sudo.
Ist er nicht in der Gruppe sudo, verwende ich su. Ein möglicher Eintrag in /etc/sudoers für docker kann nicht berücksichtigt werden, ist einfach nicht feststellbar, nicht einmal mit sudo -l.
Außerdem testet das Skript, ob docker ohne Paßwort (einmal mit, einmal ohne sudo) starten kann. Falls ja, gibt es keine Paßwortabfrage.
Damit dürfte ich hoffentlich >95% aller su/sudo-Konfigurationen korrekt einschätzen.
Wo diese allgemeine Einschätzung nicht stimmt, kann der User über eine Option zwischen pkexec/su/sudo/gksu/gksudo/kdesu/kdesudo/lxsu/lxsudo wählen. (Vergleiche xkcd: Standards )
Damit beherzige ich jetzt auch heisenbergs Empfehlung:

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.

Darüber hinaus arbeite ich an einem Update, in dem das Skript von root gestartet werden darf, und der "echte" unprivilegierte User mit $(logname), $SUDO_USER und $PKEXEC_USER ermittelt wird, damit der die unprivilegierten Befehle ausführt.

Was für ein Aufwand, um einen einzelnen Befehl als root ausführen zu dürfen ... Würde die pkexec-Paßwortabfrage auch außerhalb von DISPLAY=:0 funktionieren, wäre ich sofort ein begeisterter polkit-Fan! Dann könnte ich auf den su/sudo/gksu/gksudo/kdesu/kdesudo/lxsu/lxsudo/$nochmehr-Urwald verzichten.

[scientific]

Erste Antwort:
https://askubuntu.com/questions/477551/ ... thout-sudo

[MartinV]

Erste Antwort:
https://askubuntu.com/questions/477551/ ... thout-sudo

Danke für den Hinweis .
Mitgliedschaft in Gruppe docker ist gefährlich, auch die erste Antwort in dem Thread zeigt eine dicke Warnung:

Warning: The docker group (or the group specified with -G) is root-equivalent

Trotz der damit verbundenen Risiken gibt es viele, die ihren User der Gruppe docker hinzufügen, um die lästige Paßwortabfrage loszuwerden.
Indem ich teste, ob docker auch ohne Paßwort erfolgreich aufgerufen werden kann, habe ich diesen Fall mit abgedeckt.

Code: Alles auswählen

docker images >/dev/null 2>&1 && echo "docker startet ohne Paßwortabfrage"

[TomL]

Um docker zu starten, braucht der user root-Rechte. Das geht z.B. auf debian mit su und root-Paßwort, und z.B. auf Ubuntu mit sudo und User-Paßwort. Weder su noch sudo funktioniert von Haus aus auf beiden Systemen, nur entweder-oder.

Ich habe das schon beim ersten Mal verstanden. Und NEIN, das root-PWD ist NIE notwendig, sondern nur die Berechtigung, einen Befehl mit root-Rechten auszuführen. Aber ich wiederhole mich jetzt noch mal: Das funktioniert einwandfrei mit pkexec OHNE Eingabe eines Passwords (deshalb ohne, eben weil das auf Konsole offensichtlich fehlerhaft ist) - aber ich halte die PWD-Eingabe hier ohnehin für überflüssig. Die Lösung ist, die Leute in eine Gruppee (NICHT! sudo) einzutragen und die Gruppe via PKLA zu berechtigen. Diese User brauchen für den Start von Docker KEIN root-Password, sondern nur die explizite Berechtigung, diesen Befehl mit root-Rechten auszuführen. Und genau das kann das Polkit mit pkexec perfekt. Die PWD-Abfrage ist außerdem sowieso unnötig, wenn sie eh ihr eigenes PWD eingeben. Und wenn Hinz und Kunz das root-PWD kennt, dann kann man das PWD explizit für diesen Befehl auch einfach komplett deaktivieren.

Ich glaube, Dein Problem ist im Moment eine eigene Blockade... weil ein technisches Problem ist das jedenfalls nicht....

[scientific]

Und das pkla-File kann man in der Installation gleich mitinstallieren.

[MartinV]

Ich fürchte, wir reden aneinander vorbei.

Natürlich ist es möglich, pkexec so zu konfigurieren, daß ich einen root-Befehl (hier docker) ohne Paßwort starten kann.
Und es gibt noch mehr Möglichkeiten, das System so zu konfigurieren, daß docker ohne Paßwort startet, z. B. Mitgliedschaft in Gruppe docker.

Darum geht es aber nicht.
Die Fragestellung ist, wie distributionsübergreifend eine Paßwortabfrage zur Erlangung von root-Rechten möglich ist.
pkexec sollte das können, hat aber einen Bug in der Paßwortabfrage, kann es also nicht.

Das System passend zum Skript umzukonfigurieren, ist keine Option. Das Skript soll auf beliebigen Systemen laufen, ohne daß man erst am System schrauben muß.

Da es für die Problemstellung keine allgemeingültige Lösung zu geben scheint, nutze ich jetzt die oben beschriebene Näherungslösung.

[TomL]

Darum geht es aber nicht.

Und genau das verstehe ich nicht. Es gibt ja nur 2 Möglichkeiten.....

...erstens sie geben das Root-Passwort ein. Aber in dem Fall braucht man weder "sudo" noch "pkexec", sondern lässt den User sich via "su" als "root" anmelden und das Problem ist gelöst.

Zweitens, wenn man berechtigter Weise "erstens" nicht will, weil eben normale User das "root"-Password nicht kennen sollten, geben sie ihr eigenes Password zur Autorisierung ein. Und genau dann wirds wieder absurd, weil sie zweimal ihr eigenes Password eingeben sollen, einmal bei der Anmeldung, und dann noch mal, bei einem bestimmten Kommando. Und da frag ich "was soll dieser Quatsch?". Die User haben sich doch bei der Anmeldung identifiziert, wieso sollen sie das denn jetzt noch mal tun?

Oder hantierst Du noch mit einem dritten Password...?.. was ich mir ja kaum vorstellen kann. Welches Password, dass eingegeben werden soll, möchtest Du erzwingen? Das eigene? Obwohl sie es schon eingegeben haben? Wieso also noch mal? Das root-PWD? Dann brauchts kein pkexec und kein sudo. Sorry... ich verstehs nicht.....

[MartinV]

Und genau das verstehe ich nicht. Es gibt ja nur 2 Möglichkeiten.....

...erstens sie geben das Root-Passwort ein. Aber in dem Fall braucht man weder "sudo" noch "pkexec", sondern lässt den User sich via "su" als "root" anmelden und das Problem ist gelöst.

Leider nein - wenn root kein Paßwort hat, geht su nicht.
In dem Fall geht gewöhnlich stattdessen sudo.

Es ist aber nicht sicher feststellbar, ob su oder sudo zur Erlangung von root-Rechten geht.

[TomL]

OK, dann ist das geklärt, dann bleibt ja NUR das Polkit als Lösung. Und dann ist m.E. festzustellen, dass doch eigentlich gar kein Problem besteht.... oder eben nur dadurch, dass Du verlangst, dass der User zweimal sein eigenes Password eingibt. Und es bleibt die Frage: Warum soll der User sein eigenes Password zweimal eingeben?

[TRex]

Ja, und was hat das eigentlich noch mit dem Problem des TE zu tun?

[TomL]

Ja, und was hat das eigentlich noch mit dem Problem des TE zu tun?

Ich habe verstanden, dass es darum geht,ein Programm durch normale User mit root-Rechten zu starten.... und das unter der Bedingung, dass er nicht weiss, ob "sudo" installiert ist oder ob ein root-PWD vergeben ist und "sudo" möglicherweise nicht verfügbar ist. Für dieses Problem ist m.E. das polkit die Lösung. Aber offensichtlich stimmt das nach Deiner Meinung so nicht. Jetzt bitte ich Dich natürlich mir zu erkären, worums hier wirklich geht... bzw. wo mein Irrtum ist und was das wirkliche Problem ist?

[TRex]

Sorry, voreilige Rückfrage. TE beteiligt sich ja noch...

[MartinV]

Jetzt bitte ich Dich natürlich mir zu erkären, worums hier wirklich geht... bzw. wo mein Irrtum ist und was das wirkliche Problem ist?

Zusammenfassung:
Auf Linux ist es üblich, als unprivilegierter User angemeldet zu sein.
Um Befehle mit root-Rechten auszuführen, muß ein Paßwort eingegeben werden.
pkexec hat einen Bug und ist nicht in der Lage, zuverlässig eine Paßwortabfrage durchzuführen.
su geht nur, wenn root ein Paßwort hat.
sudo geht nur, wenn /etc/sudoers entsprechend konfiguriert ist.
Ob su oder sudo geht, ist nicht sicher feststellbar.
Das System paßwortlos umzukonfigurieren, ist für mich keine Option.

Für mich ist das Problem mit der oben beschriebenen Näherungslösung erledigt.

[TomL]

Für mich ist das Problem mit der oben beschriebenen Näherungslösung erledigt.

Das ist für mich auch völlig ok. Ich habe jetzt nur noch nur zwei Verständnisfragen, einfach nur aus persönlicher Neugier... weil ich diese Aussage als völlig ungenau empfinde:

Das System paßwortlos umzukonfigurieren, ist für mich keine Option.

1. Ist für Dich einen einzelnen (explizit erlaubten) Befehl mit Root-Rechten ohne PWD-Abfrage abzusetzen, gleichbedeutend mit "allgemein das System umkonfigurieren"?
2. Welches Password soll in Deinem Modell der User eingeben? Sein eigenes oder das root-Password?

[MartinV]

1. Ist für Dich einen einzelnen (explizit erlaubten) Befehl mit Root-Rechten ohne PWD-Abfrage abzusetzen, gleichbedeutend mit "allgemein das System umkonfigurieren"?

Ja. Das System muß dafür umkonfiguriert werden. Auch wenn es nur eine einzige Zeile irgendwo in /etc ist.

2. Welches Password soll in Deinem Modell der User eingeben? Sein eigenes oder das root-Password?

Das, womit er den root-Befehl ausführen kann. Bei su ist es das root-Paßwort, bei sudo ist es das User-Paßwort.

Wenn jemand für sich entscheidet, das System für einen paßwortlosen Start des Befehls umzukonfigurieren, kann er das tun. Aber verlangen oder voraussetzen werde ich das nicht.

[TomL]

Bitte nimm das jetzt nicht persönlich, aber ich habe das Gefühl, dass Du an dieser Stelle irgendwas noch nicht verstanden hast. Fakt ist, sowohl die Kenntnis des root-Passwords als auch die Verwendung von "sudo" bei gleichzeitiger Mitgliedschaft des Benutzers in der Gruppe "sudo" ermöglichen erst, dass der User das System verändern kann.

Ich spreche hingegen davon, dass der Benutzer absolut GAR NICHTS am System verändern kann und für keine einzige Veränderung ein Password bekommt. Stattdessen können speziell ausgewählte Benutzer nur einen einzelnen Befehl starten, für den normalerweise root-Rechte notwendig sind, aber diese User wissen das nicht. Den Usern ist im Gegensatz zu "su" und "sudo" kein anderer Befehl möglich. Alle anderen User werden bei diesem Befehl und auch bei allen anderen Befehlen abgewiesen. Schwammige Zustände wie mit "sudo" gibt es erst gar nicht.

Ist aber auch egal... wird schon passen....