ubuntuusers.de

noisefloor schrieb:

@UlfZibis: was meinst du mit "Aus der Ferne"

Damit meine ich den "Remote"-Zugriff vom entfernten Rechner. Das ist nur so eine optionale Idee, die man hier vielleicht mit aufführen könnte, um von hier auf den dafür spezialisierten Artikel zu verweisen.

Außerdem fände ich es ganz hilfreich im Artikel auf die einfache Zugriffsmöglichkeit per Nemo hinzuweisen. Damit lässt sich jedes Verzeichnis als Admin in einem weiteren Fenster öffnen. Man kann dann Dateien bequem durch Doppelklick öffnen und bearbeiten, und in /usr/share/applications/ auch grafische Programme starten.

UlfZibis schrieb:

… Außerdem fände ich es ganz hilfreich im Artikel auf die einfache Zugriffsmöglichkeit per Nemo hinzuweisen. …

Auf welches nemo beziehst du dich? Doch nicht etwa auf die alte Version, als es gksu noch gab? (vgl. Nemo auf 18.04 ermöglichen)

PS: gerade nemo in bionic installiert; verfügt noch über die Möglichkeit Als Systemverwalter öffnen. Aber ein zweiter Dateimanager ist nicht jedermanns Sache.

fleet_street schrieb:

PS: gerade nemo in bionic installiert; verfügt noch über die Möglichkeit Als Systemverwalter öffnen. Aber ein zweiter Dateimanager ist nicht jedermanns Sache.

Jedesmal wegen pkexec o.ä. die Konsole bemühen zu müssen, aber auch nicht. 😉 Also die Wahl dem User überlassen, und beide Möglichkeiten im Artikel erwähnen. Ich denke, wer sich mit root-geschützten config-Dateien und anderen fortgeschrittenen Themen beschäftigt, ist von Nautilus wegen seiner eingeschränkten Möglichkeiten, die wohl den DAU schützen sollen, eh genervt.

Hallo in die Runde,

was wird mit dieser Aussage aus dem Wiki?

Da sudo -H also nicht immer funktioniert und auch keine grafische Passwortabfrage erfolgt, sollten grafische Anwendungen (unter anderem Benutzer) grundsätzlich über die grafischen Alternativen (wie gksudo/kdesudo) gestartet werden.

Hallo,

was wird mit dieser Aussage aus dem Wiki?

Keine Ahnung - ich für meine Teil kann auch nicht sagen, ob das wirklich stimmt bzw. wo was wann nicht funktioniert.

Die 2. Frage wäre, ob pkexec GUI_PROGRAMM denn immer funktioniert...

Gruß, noisefloor

Berlin_1946 schrieb:

Hallo in die Runde,

was wird mit dieser Aussage aus dem Wiki?

Da sudo -H also nicht immer funktioniert und auch keine grafische Passwortabfrage erfolgt, sollten grafische Anwendungen (unter anderem Benutzer) grundsätzlich über die grafischen Alternativen (wie gksudo/kdesudo) gestartet werden.

Ja aber das beisst sich die Katze in den Schwanz oder, Gksudo ist raus aus den Quellen, Sinnvolle Entscheidung? Was ist den eigtl. so schlimm daran, wenn man eine GUI mit gksudo startet?

Hallo Steev,

Was ist den eigtl. so schlimm daran, wenn man eine GUI mit gksudo startet?

Nichts, es wird ab 18.04 nicht mehr funktionieren.

Was besagt der Satz:

Da sudo -H also nicht immer funktioniert

Auf welche Programme trifft das zu?

Kann der Trick mit dem "anderen Benutzer" dann noch angewendet werden?

Steev schrieb:

Berlin_1946 schrieb:

Hallo in die Runde,

was wird mit dieser Aussage aus dem Wiki?

Da sudo -H also nicht immer funktioniert und auch keine grafische Passwortabfrage erfolgt, sollten grafische Anwendungen (unter anderem Benutzer) grundsätzlich über die grafischen Alternativen (wie gksudo/kdesudo) gestartet werden.

Ja aber das beisst sich die Katze in den Schwanz oder, Gksudo ist raus aus den Quellen,

Der Artikel wird ja überarbeitet.

Sinnvolle Entscheidung?

Ja, weil das Paket schon seit Jahren nicht mehr gepflegt wird und es Alternativen dazu gibt.

Was ist den eigtl. so schlimm daran, wenn man eine GUI mit gksudo startet?

Einerseits könnten Sicherheitslücken in gksudo ausgenutzt werden. Andererseits, und noch viel wichtiger, laufen dann teilweise mehrere Prozesse unnötigerweise mit erhöhten Rechten. Angenommen, du möchtest Änderungen in der fstab abspeichern. Dazu brauchst du lediglich für den Schreibvorgang Root-Rechte. Die graphische Benutzeroberfläche und alle nötigen und unnötigen Plugins funktionieren auch mit normalen Userrechten. Wird eine Sicherheitslücke in einem Plugin ausgenützt, sind die Auswirkungen auf dein System folglich weniger schlimm.

Ausserdem funktioniert gksu mit Wayland auch nicht mehr und früher oder später werden die meisten Distributionen wahrscheinlich auf Wayland umsteigen.

Der Artikel bedarf jetzt dringend einer Überarbeitung, weil das Paket gksu in Ubuntu 18.04 LTS überhaupt nicht mehr vorhanden (nicht mehr nur kein Standard) ist, obwohl dort Wayland (noch?) nicht Standard ist. Die Befehle gksu, gksudo, kdesu usw. sind damit definitiv deprecated.

Einfach pkexec als Ersatz für gksudo vorzuschlagen geht auch nicht, da sich viele graphische Programme (z.B. auch gedit) damit nicht oder nicht ohne weiteres starten lassen.

Als etwas unschöner Ausweg bleibt derzeit wohl nur, die betreffenden Programme von einem Terminal aus (wichtig!) mit sudo -H PROGRAMM zu starten. Ich sehe nicht, welche Probleme dadurch bei graphischen Programmen auftreten könnten, wenn man konsequent die Option -H verwendet. Falls es eine bessere Lösung geben sollte, würde mich diese sehr interessieren!

Wegen einiger thematischer Überschneidungen müssten außerdem die Artikel sudo und policykit besser aufeinander abgestimmt und mit Verweisen ausgestattet werden.

Meiner Ansicht nach besteht Handlungsbedarf, denn es handelt sich um ein wichtiges und grundlegendes Thema. Ich habe deshalb eine Aufforderung zur Überarbeitung angebracht.

Gruß – Max-Ulrich

Hallo,

Meiner Ansicht nach besteht Handlungsbedarf, denn es handelt sich um ein wichtiges und grundlegendes Thema. Ich habe deshalb eine Aufforderung zur Überarbeitung angebracht.

Wir haben intern im Wikiteam schon einen Konsenz, wie das Thema angegangen wird. Es wird einen neuen Artikel geben. Stay tuned for more ☺

Ich sehe nicht, welche Probleme dadurch bei graphischen Programmen auftreten könnten, wenn man konsequent die Option -H verwendet.

Ich auch nicht.

Falls es eine bessere Lösung geben sollte, würde mich diese sehr interessieren!

pkexex ist schon gut, braucht aber pro GUI-Programm eine .policy Datei mit der passenden Regeln. Was an sich nicht schlecht ist. Sehr gut ist auch das admin:// Interface aus GVFS seit Ubuntu 17.04. Damit spart man sich zumindest beim Editieren von Dateien, sudo oder pkexec.

Gruß, noisefloor

Dass pkexec nicht immer klappt, ist nicht so toll. Aber bei sudo -H werden sicherlich viele das -H vergessen oder bei Problemen jeglicher Art mal weglassen...

Wer nur sudo kennt, wird sicher noch weniger als pkexec einsehen, dass man da manchmal -H braucht...schwer vermittelbar. Einheitsbrei sudo/ sudo -H. Muss man eben im Forum testen, ob es viele Supportfälle werden.

noisefloor schrieb:

pkexex ist schon gut, braucht aber pro GUI-Programm eine .policy Datei mit der passenden Regeln.

Im Netz kursiert ein Tipp, wie sich ausnahmslos alle GUI-Programme via pkexec mit Root-Rechten starten lassen. Eine jeweils zugehörige .policy-Datei ist hierfür nicht erforderlich!

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY PROGRAMMNAME

Per Alias ließe sich diese Übergabe der "fehlenden" Umgebungsvariablen noch bequem abkürzen. Frage: Bestehen gegen diese Verfahrensweise irgendwelche (Sicherheits-)Bedenken?

Hallo,

baue ich bei Gelegenheit mal in den PolKit Artikel ein.

Sicherheitsbedenken gibt IMHO keine, weil die .policy Datei wohl letztendlich auch nicht anders macht, als die beiden Umgebungsvariablen setzen.

Gegen ein Alias spricht eigentlich, dass man "stumpf" jedes GUI Programm mit Root-Rechten starten, egal ob nötig oder nicht. Das bewußte Schreiben von pkexec env ...oder das Schreiben einer .policy Datei ist da IMHO schon sinniger, im Sinne von "denk' drüber nach".

Gruß, noisefloor

Ich habe nach Grübeln über den Manpages zu sudo und sudoers im letzten Vierteljahr die Änderung der Variable HOME zum Standard gemacht, d. h. die Option -H wird sozusagen immer verwendet, auch wenn nicht explizit angegeben.

fleet@street ~ $ sudo ls -l /etc/sudoers.d/              # Ausgangssituation
insgesamt 12
-r--r----- 1 root root  958 Mär 30  2016 README
fleet@street ~ $ sudo bash -c env | grep HOME
HOME=/home/fleet
fleet@street ~ $ sudo visudo -f /etc/sudoers.d/user-defined       # Änderung
fleet@street ~ $ sudo cat /etc/sudoers.d/user-defined            # anschauen
# Override built-in defaults, i. e. set HOME to target fleet
Defaults           env_keep -= "HOME"
Defaults           always_set_home

fleet@street ~ $ sudo bash -c env | grep HOME         # gewünschtes Ergebnis
HOME=/root
fleet@street ~ $ sudo pluma
fleet@street ~ $ find ~ -user root
fleet@street ~ $ 

Nachteil: «sudo chown -R $USER: $HOME» funktioniert nicht mehr, wird aber auch nicht mehr gebraucht! 😛

Der Vorschlag von fleet_street hilft sicher, dass man die Option -H nicht vergisst, was sonst leicht geschehen kann.

Es bleibt aber die Tatsache, dass man die entsprechenden Programme von einem Terminal aus starten muss, da sonst eine Eingabe des Passworts nicht möglich ist. Das war ja mit gksudo anders.

Die vorhandenen Starter für manche Programme, die eine Authentifizierung brauchen (z.B. "Samba"), gehen deshalb auch nicht mehr.