ubuntuusers.de

Ubu-tester schrieb:

moin,

ich habe hier Xubuntu V18.04 drauf mit 'gksu'. Habe ich von Anfang an problemlos am laufen. Brauche ich für den Gnome-Commander mit Adminrechten und eigenen Programm. Bisher kein Problem damit. Habe ich aus der 'synaptic' Paketverwaltung.

Kann nicht stimmen: gksu

PressureCooker schrieb:

Habs' etwas ausgebaut und yags genannt.

Hallo PressureCooker, vielen Dank für dieses Bash-Skript! Das habe ich mir gespeichert und gleich zweimal in die benutzerdefinierten Aktionen meines Dateimanagers eingebaut. Jetzt kann ich Ordner wieder mit vollen Root-Rechten in PCManFM öffnen und auch einzelne Dateien ebenfalls mit Root-Rechten im Texteditor. 👍

Eine Alternative zu dem Skript findet sich in der Diskussion zum Artikel sudo ▶ https://forum.ubuntuusers.de/post/8970649/

Ubu-tester schrieb:

ich habe hier Xubuntu V18.04 drauf mit 'gksu'.

hast Du nur, weil Du 18.04 nicht neu installiert hast, sondern ein Upgrade durchgeführt hast ohne aufzuräumen ...

moin,

habe V18.04 auf eine eigene Partition alleine, frisch installiert! Ist aber schon etwas her, vielleicht gab es da noch 'gksu'.

Und wenn ich jetzt 'gksu' in 'synaptic' aufrufe, erscheint es dort, wahrscheinlich aber, weil es installiert ist.

Es funktioniert auch. ich würde es dann über einen anderen Weg installieren.

Neue Version:

• Prüft, ob GUI läuft

• Name geändert auf gksu

Wenn man es jetzt in /usr/local/bin legt, ist es systemweit zugänglich. Dann funktioniert der Befehl gksu wieder überall - auch von einem launcher aus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

#!/bin/bash
#
# gksu replacement
# 
# save as /usr/local/bin/gksu
# mark executable: chmod +x /usr/local/bin/gksu
# set readonly for all, writable for root and group root
# use gksu command as usual

# exit, if no gui
if ! [ x$DISPLAY != x ] ; then
  echo "no gui detected - exiting!"
  exit 1
fi

# fetch command to execute
execcmd=$@

# fetch current user name
curuser=$(whoami)

# message to show
msg="sudo $execcmd\n\nEnter password for $curuser:"

# request user password
if PASS=$(zenity --entry --hide-text --text "$msg" --title "GKSU" 2> /dev/null); then
  if ! [ -z $PASS ]; then
    # check if password is valid
    echo "$PASS" | sudo -S -i -k pwd > /dev/null 2> /dev/null
    if ! [ $? -eq 0 ]; then
      # password is not valid: show warning
      zenity --warning --no-wrap --text "The password supplied was invalid!" --title "GKSU" 2> /dev/null
    else
      # password is valid: execute command
      echo "$PASS" | sudo -S -i -k $execcmd 2> /dev/null
      # eval exit code of command
      if ! [ $? -eq 0 ]; then
        zenity --warning --no-wrap --text "The command supplied could not be executed!" --title "GKSU" 2> /dev/null
      fi
    fi
  else
    # empty password: show warning
    zenity --warning --no-wrap --text "An empty password was supplied!" --title "GKSU" 2> /dev/null
  fi
fi

# clean exit
exit 0

PressureCooker schrieb:

Neue Version (…) Dann funktioniert der Befehl gksu wieder überall - auch von einem launcher aus.

Hallo PressureCooker: Jepp, das funktioniert! Danke für das Werk. 👍

Der Wrapper von Seahawk aus dem Thread, den fleet_street hier verlinkt hat, ließ sich bei mir nämlich nur aus dem Terminal starten, aber das „neue gksu“ kann man auch – so wie früher – im Ausführen-Dialog verwenden und auch in den Benutzerdefinierten Aktionen des Dateimanagers. In dieser Aktion hier heißt bei mir die Exec-Zeile bloß noch

Exec=gksu pcmanfm %u

und es funktioniert wie gewünscht.

▶ Was aber hier im Thread noch gar nicht erwähnt wurde ist, dass Zenity installiert sein muss. ◀

Außerdem frage ich mich, ob du das Skript nicht an geeigneter Stelle im Wiki verewigen solltest, beispielsweise hier.

umbhaki schrieb:

In dieser Aktion hier heißt bei mir die Exec-Zeile bloß noch

Exec=gksu pcmanfm %u

Und bei mir:

Exec=sh -c "pkexec pcmanfm %u"

Dies nur, weil mancher, der hier mitliest, inzwischen den Eindruck gewinnen könnte, es funktioniere gar nicht mit pkexec. 😉

Voraussetzung ist eine .policy-Datei im Ordner /usr/share/polkit-1/actions, die bei mir org.freedesktop.policykit.pcmanfm.policy heißt und folgenden Inhalt hat:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

<?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="org.freedesktop.policykit.pkexec.pcmanfm">
    <description>Run PCManFM program</description>
    <message>Passwort erforderlich, um PCManFM zu starten</message>
    <icon_name>accessories-text-editor</icon_name>
    <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/bin/pcmanfm</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
    </action>
</policyconfig>

coram schrieb:

… den Eindruck gewinnen könnte, es funktioniere gar nicht mit pkexec. 😉

Hallo coram, diesen Eindruck wollte ich nicht erwecken, aber sicher ist es gut, dass du ihn handfest ausgeräumt hast.

Voraussetzung ist eine .policy-Datei im Ordner …

Das ist für mich die Hürde und wahrscheinlich nicht nur für mich. Bei mir ist nämlich der Versuch gescheitert, hinter die (Konfigurations-)Geheimnisse von pkexec zu kommen. Dass es so eine Datei in /usr/share/polkit-1/actions braucht, habe ich bei meinen Recherchebemühungen auch noch kapiert, aber auch die Beispieldateien, auf die ich gestoßen bin, haben mir nicht weit genug geholfen, weder um selber eine zu schreiben, noch um überhaupt jede Zeile darin zu verstehen.

Das Skript von PressureCooker dagegen hätte ich zwar selber auch nicht schreiben können, aber wenn ich das drölfmal gaanz laaangsam lese, dann verstehe ich immerhin noch, was es macht. Deshalb ist es für mich die angenehmere Lösung. Zumal es ohne weitere Umstände universell nutzbar ist, also damit nicht nur der Dateimanager, sondern bsw. auch der Texteditor mit Root-Rechten gestartet werden kann. Wie mit dem alten gksudo eben.

Was ich wiederum nicht beurteilen kann ist, ob es irgendwelche Sicherheit-Abstriche bei dieser Lösung gibt. Diesbezüglich dürfte pkexec wohl vorne liegen, vermute ich. Nur ist das für mich als Alleinherrscher über meine Rechner nicht so sehr von Bedeutung.

Bisher konnte ich Thunar mit dem Befehl gksu xdg-open %F als Administrator bzw. root starten und damit auf alles zugreifen, wenn ich es denn wollte. Das war angenehm und ich wusste auch, was ich tat. Leider ist das durch den Wegfall durch gksu jetzt nicht mehr möglich! Alles ist viel komplizierter geworden... Kann mir jemand evtl. einen Weg zeigen, wie ich weiterhin Thunar als Administrator bzw. root öffnen kann?! Freundl. Gruß Martin

nehemia777 schrieb:

Bisher konnte ich Thunar mit dem Befehl gksu xdg-open %F als Administrator bzw. root starten und damit auf alles zugreifen, wenn ich es denn wollte. Das war angenehm und ich wusste auch, was ich tat. Leider ist das durch den Wegfall durch gksu jetzt nicht mehr möglich! Alles ist viel komplizierter geworden... Kann mir jemand evtl. einen Weg zeigen, wie ich weiterhin Thunar als Administrator bzw. root öffnen kann?! Freundl. Gruß Martin

Nimm das Skript weiter oben: https://forum.ubuntuusers.de/post/8972961/

Du brauchst dafür auch Zenity: https://wiki.ubuntuusers.de/Zenity/

Dann kannst du wie gewohnt weiter gksu verwenden.

Warum nicht einfach von hier (ich hab' das 16.04 deb genommen) downloaden und per gdebi installieren ?

umbhaki schrieb:

(...)

▶ Was aber hier im Thread noch gar nicht erwähnt wurde ist, dass Zenity installiert sein muss. ◀

Rein aus Interesse: Würde stattdessen nicht auch der Befehl su-to-root aus dem Paket menu funktionieren; Zitat aus su-to-root: ???

NAME
su-to-root - A simple script to give an interactive front-end to su.
It can be used in menu entry commands to ask for the root password
SYNOPSIS
su-to-root [-X] [-p <user>] -c <command>
DESCRIPTION
Most menu entries simply start an editor or a game or whatever. But some menu entries would like to give the user the ability to change important settings in the system, that require root privileges.
su-to-root can be used to ask for the root password.
OPTIONS

• c <command>
  The command to execute as a string. This option is mandatory.
  

• p <user>
  The name of the user to change to, instead of root.
  

• X The command is a X11 program that does not require a terminal.
  This is to be used with menu entries that declare needs="X11".
  

ENVIRONMENT
SU_TO_ROOT_X
Select the su-like program called by su-to-root -X. Supported
values are gksu, kdesu, kde4su, ktsuss, sux, gksudo and kdesudo. kde4su denotes the KDE4 version of kdesu.
When this variable is not set su-to-root will currently try to use gksu, kdesu, kde4su, ktsuss, sux and the built-in code, in that order with the exception that under a KDE session, kdesu and kde4su are prefered over gksu.
The exact set of programs to try and their order is subject to change without notice.
SU_TO_ROOT_SU
Select the su-like program used in text mode. Supported values are sudo, sux and su, the first being the default in Ubuntu (configured in /etc/su-to-rootrc).

linux_joy schrieb:

Rein aus Interesse: Würde stattdessen nicht auch der Befehl su-to-root aus dem Paket menu funktionieren; Zitat aus su-to-root: ???

Das ist laut Beschreibung, die du gepostet hast, zunächst ebenfalls ein Wrapper, der aber auch einen eigenen Code hat. Auf diesen eigenen Code sollte er beim Aufruf mit -X zurückfallen, wenn die Umgebungsvariable SU_TO_ROOT_X nicht definiert ist und weder gksu, kdesu, kde4su, ktsuss noch sux installiert sind bzw. gefunden werden können.

Blöd wär nur, wenn die Entwickler diesen eigenen Code demnächst aus den gleichen Gründen rausschmeißen, aus denen Canonical auf gksu verzichtet hat.

In der Beschreibung steht ja explizit: The exact set of programs to try and their order is subject to change without notice.

Am Ende ist der eigene Code identisch mit dem von gksu, dann wäre es nur eine Frage der Zeit ☺

Könnte also klappen, solange der eigene Code noch da ist. Probiers' doch mal aus und berichte.

PressureCooker schrieb:

(...)

Blöd wär nur, wenn die Entwickler diesen eigenen Code demnächst aus den gleichen Gründen rausschmeißen, aus denen Canonical auf gksu verzichtet hat.

In der Beschreibung steht ja explizit: The exact set of programs to try and their order is subject to change without notice.

Am Ende ist der eigene Code identisch mit dem von gksu, dann wäre es nur eine Frage der Zeit ☺

Könnte also klappen, solange der eigene Code noch da ist. Probiers' doch mal aus und berichte.

Hallo,

ich hab's mal unter Lubuntu 14.04 ausprobiert, allerdings musste ich dafür zunächst das Paket menu installieren:

• die Umgebungsvariable SU_TO_ROOT_X ist nicht definiert

• die Umgebungsvariable SU_TO_ROOT_SU ist ebenfalls nicht definiert, aber in /etc/su-to-rootrc steht: SU_TO_ROOT_SU=sudo

Also wird beim Aufruf von su-to-root -X -c pcmanfm wahrscheinlich letztlich auch gksu benutzt.