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

[MartinV]

Die Antwort scheint sehr eindeutig. Mitglieder der Gruppe sudo sollen root werden können.

Womit wir einen Mischmasch aus sudo und policykit haben.
Die entsprechende Einstellung findet sich hier:

Code: Alles auswählen

$ cat /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf 
[Configuration]
AdminIdentities=unix-group:sudo

Er schreibt als Begründung:

> Command sudo and group sudo were designed to allow single privileged commands for unprivileged users.

This is not correct. The default sudo config ships

%sudo ALL=(ALL:ALL) ALL

I.e., a user in group sudo can run every command with root privileges.

Aber wenn ich das auskommentiere, werde ich mit pkexec und Gruppe sudo immer noch root für beliebige Befehle:

Code: Alles auswählen

# %sudo	ALL=(ALL:ALL) ALL

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

Ich habe sudo nachträglich installiert und User 1000 hinzugefügt und /etc/sudoers editiert, um nur einen einzigen Befehl zu erlauben. (Ich war brav, und habe sudo so verwendet, wie es 1980 gedacht war!)

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.

Mir geht es gerade ähnlich - durch die Vermischung der Gruppe sudo mit policykit (als debian-default!) habe ich unbeabsichtigt User 1000 volle root-Rechte mit pkexec gegeben, obwohl ich nur einen einzelnen Befehl mit sudo ermöglichen wollte. Für mich heißt die Konsequenz, daß ich jetzt auch sudo in jeder Form meide - aber eigentlich nur, weil die Konfiguration von pkexec unsauber ist, was die Gruppe sudo angeht.

Das mindeste sollte eine Warnung wegen pkexec in der /etc/sudoers sein; es ist nicht mehr möglich, mit sudo einzelne Befehle zu erlauben, es geht nur alles oder nichts. Sauber wäre es gewesen, eine neue Gruppe "pkexec" anzulegen, anstatt die Gruppe "sudo" zu mißbrauchen.

Gibt es irgendwo einen schönen Beleg, daß sudo für einzelne Befehle gedacht war, den ich im Bugreport zitieren kann? Die Manpages von sudo und sudoers sind lang, einen prägnanten Satz, der das zusammenfaßt, habe ich nicht gefunden.

[brummer]

Ich kann hier (debian/sid) dies probleme mit pkexec oder sudo nicht nachvollziehen.
Beides funktioniert hier wie es soll.
In pkexec muss jeder Befehl der auszuführen ist, in einer rules Datei stehen. Inclusive Pfad zur exe. Ob eine Passwort abfrage nötig ist oder nicht, kann man in den rules für jeden einzelnen Befehl festlegen.
Alle anderen Befehle werden verweigert.
pkexec rules müssen als root angelegt werden. Also, wenn, z.b. /usr/bin/sudo in pkexec eingetragen ist, ist der system admin sofort zu entlassen, denn das hebelt pkexec natürlich aus.
Mit sudo kann ich mich kurzfristig als user mit root rechten ausstatten (nach Passwort abfrage) und Befehle ausführen die root rechte verlangen.
Ganz gewiss kann ich nicht mit meinem user Passwort über pkexec irgendwelche root befehle ausführen.
Wäre das der Fall würde ich meine Distribution, wegen Vertrauensverlust, sofort wechseln, dann das setzt unseriöse default polkit rules voraus.

[MartinV]

Ganz gewiss kann ich nicht mit meinem user Passwort über pkexec irgendwelche root befehle ausführen.

Das ist der Punkt, auf dem ich herumreite. Als Mitglied der Gruppe sudo kann ich mit pkexec und User-Paßwort root werden. Der Inhalt von /etc/sudoers spielt dabei keine Rolle.

[brummer]

Ganz gewiss kann ich nicht mit meinem user Passwort über pkexec irgendwelche root befehle ausführen.

Das ist der Punkt, auf dem ich herumreite. Als Mitglied der Gruppe sudo kann ich mit pkexec und User-Paßwort root werden. Der Inhalt von /etc/sudoers spielt dabei keine Rolle.

Ganz gewiss nicht, ohne als root entsprechende Dateien zu editieren.

[TomL]

Das ist der Punkt, auf dem ich herumreite. Als Mitglied der Gruppe sudo kann ich mit pkexec und User-Paßwort root werden. Der Inhalt von /etc/sudoers spielt dabei keine Rolle.

Ich bin unsicher, ob Du schon mal gesagt hast, um welches OS es eigentlich geht. Mich wundert das alles, weil Debian das eigentlich gut und imho auch konfliktfrei handhabt. Gemäß der Default-Einstellungen beim Installer ist "sudo" erst mal gar nicht scharf geschaltet, dafür hat root jedoch ein Password. Debian ist bei einer Default-Installation komplett so ausgestaltet, dass es für nichts die Verwendung "sudo" vorsieht oder gar verlangt. Wer es haben will, muss es selber "scharf" schalten. Das, was Du beschreibst, klingt viel mehr nach Ubuntu oder Mint... und gerade die haben das imho total verhunzt.

Also, um welches OS gehts hier eigentlich? Isses wirklich Debian? Mich störts nicht, wenns ein anderes ist.... aber neugierig bin ich schon.

[MartinV]

Es ist debian stretch.
Installiert habe ich es mit root-Paßwort, ohne sudo.

sudo habe ich nachträglich installiert und /etc/sudoers editiert.
policykit und seine Konfiguration habe ich nicht angetastet.

Ich lade gerade eine Live-CD herunter, um die Situation mit einem jungfräulichen System noch einmal nachzuprüfen.

[Dogge]

Ich kann es nachvollziehen (debian stretch buster):

Code: Alles auswählen

martin@schlepptop  ~ sudo whoami
[sudo] Passwort für martin: 
Leider darf der Benutzer martin »/usr/bin/whoami« als root auf schlepptop nicht ausführen.

Code: Alles auswählen

martin@schlepptop  ~  pkexec whoami
root

Ich habe nämlich auch ein root Passwort vergeben, da ich ja Systemeinstellungen und Paketinstallationen als root mache. Um »einen einzigen Befehl« als User mit root Rechten ausführen zu können habe ich sudo installiert und »diesen einen« Befehl erlaubt. Ich finde es krass, dass ich mir damit unwissentlich mein System wie ein Ubuntu eingerichtet habe, nur mit dem Unterschied, dass man bei Debian pkexec statt sudo voranstellen muss. Da hätte ich in der /etc/sudoers ja auch gleich alles erlauben können.

Edit: Policykit lässt sich auch nicht so einfach deinstallieren, wenn man gnome-control-center, network-manager und gdm3 behalten will:

Code: Alles auswählen

Die folgenden Pakete werden ENTFERNT:
  colord* gdm3* gnome-color-manager* gnome-control-center* gnome-system-log* network-manager* network-manager-gnome*
  policykit-1* 

Sehr schön.
D.h. ich kann jetzt nur sudo deinstallieren und die Gruppe sudo löschen, obwohl sudo tut was es soll und pkexec Mist baut.

Edit2: Vor lauter Verärgerung hab ich ganz vercheckt, dass testing jetzt ja buster heißt.

LastEdit: Naja, ich finde das Verhalten immer noch doof, aber mit den Beiden Befehlen bekommt man es gefixt:

Code: Alles auswählen

# gpasswd -d USER sudo
# groupdel sudo

[guennid]

Und was war das für'n bohai um visudo!
Es gibt noch ein weiteres Alt-Programm, um gezielt root-Rechte zu übertragen, das ich seit woody gelegentlich nutze: super

Was haltet ihr davon?

[MartinV]

Ich kann es nachvollziehen (debian stretch buster):

Danke für's Überprüfen und Bestätigen.

Sehr schön.
D.h. ich kann jetzt nur sudo deinstallieren und die Gruppe sudo löschen, obwohl sudo tut was es soll und pkexec Mist baut
[...]
mit den Beiden Befehlen bekommt man es gefixt:

Code: Alles auswählen

# gpasswd -d USER sudo
# groupdel sudo

Du kanst auch die policykit-Konfiguration für Gruppe sudo löschen:

Code: Alles auswählen

/etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf

[MartinV]

Das Rätsel um pkexec und sudo löst sich auf! Aus dem Bugreport:

> Granting root-like access via group sudo is intended and not a security
> hole and the policykit policy is in line with the sudo policy here.

This is also as documented in base-passwd, which is the central
authority on what the predefined groups in Debian mean:

sudo

Members of this group may run any command as any user when using sudo or
pkexec (from the policykit-1 package, independently of whether the sudo
package is installed).

—/usr/share/doc/base-passwd/users-and-groups.txt.gz

If you don't want a user to be root-equivalent, don't add them to the
sudo group. Users who are meant to be able to run certain specific
commands (but not others) via sudo should not be in that group;
membership of that group is not required to use sudo.

* Mitglieder der Gruppe sudo sind Administratoren und dürfen mit pkexec und User-Paßwort beliebige root-Befehle ausführen
* Um einzelne Befehle für User per sudo in /etc/sudoers zu erlauben, ist Mitgliedschaft des Users in der Gruppe sudo nicht nötig.

[scientific]

Das schrieb ich ja schon vorhin. Mitglieder der Gruppe sudo sind admins und dürfen alles.
Das sagt ja auch

Code: Alles auswählen

 %sudo	ALL=(ALL:ALL) ALL

Und pkexec bildet dieses Verhalten ebenfalls ab.

Die Frage ist, wird UID 1000 bei Vergabe eines root-Passworts im Installer der Gruppe sudo hinzugefügt oder nicht? Wenn ja, sind wir bei Windows, wenn nein, passt alles.

Nach einer vollständigen Installation MUSS ja irgend ein User Adminrechte haben. Sonst steh ich schön blöd da, will ich etwas am System verändern.
Klar, mit livesystem und chroot kann ich mir schon helfen... Aber das ist wirklich nur ein Würgaround.

Dieser Admin-User (root mit Account, oder UID 1000 in Gruppe sudo) kann dann anderen Usern einzelne Befehle durch explizites Eintragen in /etc/sudoers erlauben, oder er legt den Usern pkexec-Rules an.
In pkexec kann ich sogar unterscheiden, was der User darf, wenn er lokal an der Maschine eingeloggt ist, oder per ssh.

Ich versteh die ganze Aufregung hier nicht. Vermute einmal sie kommt daher, das sich manche mit der Konfiguration von /etc/sudoers noch nicht ausreichen beschäftigt haben... Und die Verwendung von sudo mit der Gruppenmitgliedschaft in sudo gleichsetzen...

Ich hab unlängst bei einer Installation dem User mit UID 1000 (ohne ihn der Gruppe sudo hinzuzufügen) mit pkexec erlaubt, in gnome-software neue Software zu installieren, aber keine zu löschen.
Damit kann dieser User über die Gnome-Suche Programme finden, die nicht installiert sind, und sich diese mit dem eigenen Passwort installieren, aber durch die nicht Erlaubte Deinstallation kann er sich den Boden unter den Füßen nicht wegziehen und das halbe System wegreißen.

Hab einen zweiten User als Admin angelegt, der ist in der Gruppe sudo. Und in GDM ausgeblendet mit dieser Methode:

Go to /var/lib/AccountsService/users If the user has already logged in, then there should be a file with their user name. If not, then copy a different one to a file with their user name. Edit the file and change the SystemAccount= line to true. Restart gdm and that user won't show up in the list.

Das wäre zu überlegen, ob nicht gleich auch der Installer erledigen sollte, wenn kein Rootpasswort vergeben wird, und UID 1000 in die Gruppe sudo kommt...
Damit is klar, dass ein weiterer unprivilegierter User angelegt werden sollte.

Lg scientific

[Meillo]

@scientific: Guter Post.

Das wäre zu überlegen, ob nicht gleich auch der Installer erledigen sollte, wenn kein Rootpasswort vergeben wird, und UID 1000 in die Gruppe sudo kommt...
Damit is klar, dass ein weiterer unprivilegierter User angelegt werden sollte.

Wenn man nun aber bei einem passwortlosen root einen User1 in Gruppe sudo anlegt und einen User2 ohne sudo-Zugehoerigkeit, dann kann man stattdessen auch gleich root ein Passwort geben und dem ersten User keine sudo-Zugehoerigkeit. Es laeuft auf das gleiche raus.

Die Gruppe sudo statt dem root-Account macht fuer mich dann Sinn wenn es mehrere Admins sind (es geht ja auch um die *Gruppe* sudo) und man verhindern will, dass ein Passwort geshared werden muss ... wobei sich dieser Fall durch ssh-Keys grossteils eruebrigt.

[scientific]

Ah ja. Das wars!
Stimmt. Mit einem Admin nimmt man besser einen echten root. Mit mehreren Admins dann sudo.

Mit sudo kann man ja aber auch den Zugriff auf andere Hosts auch regeln, und welche Rechte die User/Groups dort haben. Aber so weit bin ich noch nicht vorgedrungen, das zu ergründen.

Sudo hat ggü su auch den Vorteil, dass fehlgeschlagene Loginversuche gepetzt (gemailt/gelogt) werden. Bei su muss man extra /var/log/auth oder das Journal parsen.

Der Vorteil eines Admins via sudo ist ja auch, dass der gefahrlos eine graphische Sitzung starten kann. Abgesehen von der Gefahr, dass sein Passwort abgegriffen wird, und so jemand seine Sitzung und gleich den ganzen Rechner übernehmen kann.

Und man kann durchaus sudo und pkexec mischen. Denn einen einzelnen Befehl in sudo erlauben ist einfacher und verständlicher als eine pkla zu schreiben. Sich aber einmal in polkit eingearbeitet zu haben bringt wohl mehr Flexibilität und feinere Granularität als sudo.
Ich sehs so ähnlich wie mit systemd. Hat man das einmal verstanden, kann man damit super lässige Abhängigkeiten und Automatismen bauen. Was mit Shellskripten in einer Zeile erledigt wird, brauch mit systemd ein, zwei units mit mehreren Zeilen.
Benötigt man aber Abhängigkeiten, vorhandensein von Files/Directorys, Laptop am Stromkabel oder Akku artet mit Shellskripten schnell zu Megaskripten aus, die noch Funktionen sourcen, die wiederum Funktionen sourcen (man analysiere mal acpid in voller Tiefe...) bleibt aber mit systemd ein, zwei units mit ein paar Zeilen.

So kann ich mit pkexec ganz einfach den Zugriff auf eine einzige Funktion von lokal und remote verschieden Regeln. Mit sudo wird das schon schwierig... Wenn es überhaupt geht.

Gruppenweise Rechtevergabe geht in pkexec genauso einfach wie in sudo.

Btw... Ich hab grad beschlossen, msudo von meinen Maschinen zu schmeißen, und mich in pkexec einzuarbeiten. Aber dennoch halte ich richtig eingesetztes sudo nicht für ein Risiko.

[TomL]

Denn einen einzelnen Befehl in sudo erlauben ist einfacher und verständlicher als eine pkla zu schreiben.

Und das ist der beliebte Irrtum, wo schlichtweg die Realität (vielleicht auch unbewusst) ignoriert wird. Mit dem per default konfiguriertem 15-minütigen Passwdkeep im "sudo"-Kommando öffnest Du eine Sicherheitslücke, mit der sich wirklich jedes Programm, jedes Plugin, jedes Addon im Vorbeigehen root-Rechte erschleichen kann und damit die vollständige Kontrolle über den Rechner erlangt. Das wissen die wenigsten und die wenigsten schalten das ab. Das wäre beispielsweise DIE offene Tür für den Bundestrojaner... es braucht nur ein ge'hype'tes Addon über Computerbild oder Chip.de o.ä. ... oder vielleicht so interessante Programme wie Calibre, die wohl oft nicht aus dem Repo kommen..... und Peng, der Rechner ist gekapert. Das spannende dabei ist, dass wohl niemand auf den Komfort des Password-Keeps verzichten will, denn dann müsste man ja bei mehreren sudo-Kommandos jedesmal das Passwd eingeben. Aber genau das ist der Knackpunkt.... wer nur einmal das Pwd eingeben will, der nimmt einfach "su"... Problem gelöst.

Fakt ist, es gibt außerhalb der Situation, dass mehrere Admins vollständig berechtigt werden sollen, keinen sinnvollen Einsatz von "sudo" auf einem Desktop-PC, am allerwenigsten, wenn es um diese einzelnen Single-Statements geht. Das polkit ist aber so flexibel, dass man sowohl explizite Berechtigungen (analog sudoers) aussprechen kann und darüber hinaus "sudo" auch für Single-Statements ganz einfach und nebenbei emulieren kann. Und zwar schon auf einfachste Weise mit einem Bash-Alias:

Code: Alles auswählen

alias sudo="pkexec $@"

was auf Anhieb schon fast alle Singles-sudo-Statements erfolgreich abhandelt. Und wenn dann auch noch grafische sudo-Kommandos abgesetzt werden sollen, dann ändert man den Alias auf

Code: Alles auswählen

alias sudo="pkexec /usr/local/bin/sudo"

und verwendet einen Wrapper

Code: Alles auswählen

nano /usr/local/bin/sudo

Code: Alles auswählen

#!/bin/bash

if [[ $EUID -eq 0 ]]; then
    PATH=/usr/local/sbin:/usr/local/bin:$PATH
    export PATH
    [[ ! -z "$@" ]] && $@ && exit $?
fi

exit 1

und begleitend dazu eine einfache Policy, die darüber informiert, dass es um grafische Apps geht:

Code: Alles auswählen

nano /usr/share/polkit-1/actions/sudo.policy

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
 "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">

<policyconfig>
  <action id="LocalExtPerms.sudo">
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/local/bin/sudo</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
  </action>
</policyconfig>

Diese Policy verlangt generell das root-Passwd, eine PKLA ist nicht erforderlich. Die Polkit-Local-Autorisation braucht man erst, wenn man Abweichungen einstellen will, um z.B. User oder Gruppen mit User-PWD zu berechtigen, weil diese User das root-PWD nicht kennen. Und wer sich wider besseres Wissen auch hier für den PDWkeep entscheidet, ändert einfach "auth_admin" auf "auth_admin_keep". Dann ist sudo komplett abgebildet, einschließlich der Risiken.

Damit ist der ganz sudo-Quatsch völlig überflüssig und es funktioniert trotzdem alles wie gewohnt. Und man kann nun einfach mit sudo Terminal-Anwendungen starten und gleichermaßen auch grafische (!) Programme, ohne diese Prothesen gksudo und kdesudo und wie sie alle heissen. Diese ganze Diskussion über sudo für Desktop-Systeme ist so dermaßen absurd, dass ich das manchmal kaum noch verstehen kann.... aber über systemd wird ja genau so diskutiert...

[Dogge]

Das schrieb ich ja schon vorhin. Mitglieder der Gruppe sudo sind admins und dürfen alles.
Das sagt ja auch

Code: Alles auswählen

 %sudo	ALL=(ALL:ALL) ALL

Und pkexec bildet dieses Verhalten ebenfalls ab.

Wenn man diese Zeile aber nicht in der sudoers hat, dann darf man mit sudo nur was explizit in der sudoers erlaubt wurde. Pkexec ignoriert das aber und erlaubt weiterhin alles (sofern der user in der Gruppe sudo ist)...
Ich finde es dämlich, das über die Gruppe sudo zu regeln, da diese halt suggeriert, dass man user die sudo nutzen sollen in die Gruppe fügen muss. Man hätte doch dafür ne Gruppe admin, pkexec o.ä. anlegen können.
Klar, das ist _irgendwo_ dokumentiert aber es ist halt eine sehr fehlerträchtiges, wenn nicht gar Fehlkonfigurationen provozierendes Setup.

[scientific]

Die Zeile sollte aber in sudoers sein.
Damit ist klar, wer in der Gruppe sudo ist, ist Sysadmin und darf sowohl mit pkexec und sudo alles.

Also regle ich die Erlaubnisse des Sysadmin-Users allein durch die Zugehörigkeit der Gruppe sudo.

Das ist doch nicht so schwierig.

Will ich eigene Rechtesysteme, regle ich es über eigens erstellte Gruppen, denen ich die Erlaubnis mit sudoers und pkexec.

Sudo ist sysadmin. Das ist als Default zu akzeptieren. Sowohl für sudo als auch für pkexec. Und von pkexec zu fordern, dass es /etc/sudoers berücksichtigen soll, wäre das gleiche wie vom ftp-Server die Einstellungen von /etc/ssh/ zu berücksichtigen...

[Dogge]

Die Zeile sollte aber in sudoers sein.
Damit ist klar, wer in der Gruppe sudo ist, ist Sysadmin und darf sowohl mit pkexec und sudo alles.

Ich habe die Zeile halt rausgenommen und die sudoers so konfiguriert, dass mein Nutzer nur den einen Befehl als root ausführen darf. Dann hab ich es mit sudo getestet und es hat alles funktioniert weil sudo die Konfiguration in der sudoers berücksichtigt. Dass es pkexec gibt und das die sudoers ignoriert habe ich erst in diesem Thread erfahren.

Ich finde nicht, dass damit alles klar ist. Die Gruppe sudo hat keinen Einfluss darauf wie sudo sich verhält, da man das in der sudoers ändern kann. Pkexec hingegen wird durch die Gruppenzugehörigkeit zu sudo konfiguriert aber ignoriert die sudoers. Das finde ich alles andere als klar ersichtlich, eher "frickelig" um mal heise Jargon zu bemühen.

[scientific]

Nun... Es gibt Defaultkonfigurationen. Wenn ich solche sicherheitsrelevanten Geschichten ändere, muss ich mich vorher gut informieren.

Lass es halt wie es vorgesehen ist, und nimm deine User aus der Gruppe sudo raus. Und erlaub deinen Befehl explizit jedem User, oder mach eine neue Gruppe, erlaub ihn dieser Gruppe und füg die entsprechenden User dieser Gruppe hinzu. So würds ich lösen. Das ist überhaupt nicht frickelig.

[Dogge]

Nun... Es gibt Defaultkonfigurationen. Wenn ich solche sicherheitsrelevanten Geschichten ändere, muss ich mich vorher gut informieren.

Klar hab ich mich informiert wie ich sudo mittels der sudoers konfigurieren kann. Dass man zusätzlich noch pkexec beachten muss habe ich in keiner sudo manpage gesehen. Mir ist dieses Tool, wie ich ja schon häufiger gesagt habe, noch nie untergekommen. Ist das noch recht neu oder ist das bisher immer an mir vorbeigegangen?

Lass es halt wie es vorgesehen ist, und nimm deine User aus der Gruppe sudo raus.

Das habe ich ja gemacht und auch gleich die Gruppe gelöscht, steht so auch in einem meiner Beiträge hier.

Das ist überhaupt nicht frickelig.

Das Entfernen aus der Gruppe finde ich auch nicht "frickelig" sondern eher das Zusammenspiel von sudo, pkexec, der Datei sudoers und der Gruppe sudo.
Dass die Gruppe sudo nicht für sudo sondern für pkexec relevant ist und sudo auch ohne die Gruppe funktioniert aber pkexec wenn es schon die Gruppe sudo heranzieht nicht die sudoers berücksichtigt halte ich schon für eine mindestens seltsame Designentscheidung.
Hätte man die Gruppe statt sudo admin genannt wäre das klarer.

[Meillo]

Dass die Gruppe sudo nicht für sudo sondern für pkexec relevant ist und sudo auch ohne die Gruppe funktioniert aber pkexec wenn es schon die Gruppe sudo heranzieht nicht die sudoers berücksichtigt halte ich schon für eine mindestens seltsame Designentscheidung.

Das geht mir auch so. Da fehlt die Klarheit (die ich sonst von Unix gewohnt bin).

Hätte man die Gruppe statt sudo admin genannt wäre das klarer.

Die Gruppe adm gibt es schon. Ihre Mitglieder koennen die Logfiles lesen.


Ach, und btw: Bei BSD muss man Mitglied der Gruppe wheel sein, um su(1) aufrufen zu duerfen.

[scientific]

Wheel ist ja auch so ein Relikt, das nur durch Gewohnheit passt, sonst aber äußerst seltsam klingt...

[MartinV]

Ich muß meine [gelöst]-Meldung leider widerrufen.
Was erst eine Lösung zu sein schien, um die Anwendbarkeit von sudo für einen bestimmten Befehl zu testen:

Code: Alles auswählen

sudo -ln docker

... funktioniert leider nur, wenn sudo vorher schon mit Paßwort aufgerufen wurde und sich das Paßwort gemerkt hat. Ansonsten gibt es Fehlercode 1 zurück, auch wenn der Befehl zulässig ist.

Die Paßwortabfrage von pkexec funktioniert nur auf Display :0. Auf Konsole und auf anderen X Servern bricht es mit Fehlermeldung ab. In OpenSuse funktioniert es nicht einmal auf Display :0.
Traurige Bilanz, wenn pkexec nach 10 Jahren nicht in der Lage ist, zuverlässig eine Paßwortabfrage durchzuführen. So wird das nix mit der Ablösung von su und sudo.

Da steh ich nun, ich armer Tor, und bin so klug als wie zuvor.

[TomL]

Traurige Bilanz, wenn pkexec nach 10 Jahren nicht in der Lage ist, zuverlässig eine Paßwortabfrage durchzuführen.

Was macht Dich eigentlich so sicher, dass das Polkit das Problem ist? Ich bin eigentlich ziemlich sicher, dass es das nicht ist. Beschreibe doch einfach mal ganz präzise, was Du erreichen willst, in welchem Umfeld, mit welchen Hilfsmitteln, in welchem zeitlichen Ablauf, wer UND was ist beteiligt am Prozess? Du solltest Dich wirklich nicht wundern, wenn auf Dein Posting kein Mensch reagiert.... was ist denn das für eine Feststellung "es bricht mit einer Fehlermeldung ab", wenn es hier kein Orakel gibt, welches uns hier die Fehlermeldung zeigt. Wie soll man denn da helfen? Irgendwas hinterhertragen habe ich auch keinen Bock drauf. 3 Mal bin ich heute schon angefangen und habs jedesmal wieder abgebrochen. Aber die Aussage, dass das Polkit nicht funktioniert ist schlichtweg falsch. Und das sollte so nicht stehenbleiben.... also nun doch ein 4. Versuch.

[MartinV]

Aber die Aussage, dass das Polkit nicht funktioniert ist schlichtweg falsch. Und das sollte so nicht stehenbleiben.... also nun doch ein 4. Versuch.

Danke!

Was macht Dich eigentlich so sicher, dass das Polkit das Problem ist?

Nachdem die Verwicklungen um pkexec und Gruppe sudo geklärt sind, bleibt noch ein Problem: Die Paßwortabfrage mit pkexec. Auf Display :0 funktioniert sie. Du hast das Problem auch erwähnt:

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.

pkexec im Terminal auf Display :0 funktioniert bei mir, es kommt die GUI-Abfrage.
Auf Konsole bekomme ich diese Fehlermeldung:

Code: Alles auswählen

$ pkexec bash
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/bin/bash' as the super user
Authenticating as: root
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.

Starte ich einen zweiten X Server und rufe dort pkexec auf, kommt manchmal die pkexec-GUI auf dem ersten X Server (wo ich sie nicht sehen kann, weil ich ja die Anzeige vom zweiten X Server habe), manchmal erscheint sie auch auf dem ersten X server nicht und die Fehlermeldung wird erst sichtbar, wenn ich den zweiten X Server beende und wieder auf Konsole bin. Paßwortabfrage mit gksu funktioniert auch auf zusätzlichen X servern.

Beschreibe doch einfach mal ganz präzise, was Du erreichen willst, in welchem Umfeld, mit welchen Hilfsmitteln, in welchem zeitlichen Ablauf, wer UND was ist beteiligt am Prozess?

Eigentlich ist es eine Kleinigkeit: Ich will einen einzelnen Befehl (docker) als root ausführen und dafür das Paßwort abfragen. Der Rest des Skriptes (insbesondere verschiedene X Server, z. B. Xephyr) soll als unprivilegierter User laufen.

Ziel: GUI-Anwendungen in docker Containern ermöglichen, und dabei unter anderem Sicherheitslücken im X11 Protokoll vermeiden (z .B. Keylogging).
Umfeld: Beliebige Linux-Distributionen
Hilfsmittel: bash, docker, zusätzliche X server
Ablauf: Ein X Server wird gestartet, es erscheint eine Paßwortabfrage, um docker zu starten. Anschließend werden X Server und docker überwacht, und wenn eines von beiden beendet wird, beendet das Skript auch das andere.
Das Skript auf github: x11docker

[TomL]

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. Der Grund dafür war, soweit ich mich erinnere, dass man sich nicht einigen konnte und die dunkelblaue Tischdecke auf keinen Fall jetzt dunkelgrün sein darf. Ganz so wars zwar nicht, aber für mich ist es gleichbedeutend und auf jeden Fall völlig absurd. Es ging darum, das 0.105 pkla-Flat-Files hatte und 0.113 neuerdings die Dateien im xml-Style anlegt. Als wenn das eine Rolle spielt.... stattdessen hält man lieber an einer Bug-Version fest.

Egal... das TTY-Problem besteht aktuell in Debian. Läuft der GUI-Auth-Agent funktionierts, wenn X läuft. In der Konsole gehts nicht, weil kein X läuft und der pkttyagent failed. Das funktioniert nicht mal mit einem Prozess-Bind. 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. Und wenn der User sowieso sein eigenes PWD eingeben kann, kann man sich das doch auch sparen. 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.

Das wäre für mich nicht nur ein Workaround, sondern die Lösung... weil ich einfach in Frage stelle, ob der mit seinem PWD angemeldete User wirklich noch mal das gleiche PWD eingeben soll... ich würde das für überflüssig halten.