Arbeitsverzeichnis in Skripten

[Ulidor]

Um GUI-Programme als root aufrufen zu können, habe ich für jedes Programm ein Skript mit pkexec als normaler User angelegt und es nach /usr/local/bin verlinkt. Das funktioniert auch so weit. Allerdings bekommt das aufgerufene Programm immer /root als Arbeitsverzeichnis, anstatt das der aufrufenden Umgebung.

Das folgende Skript heißt kate_r

Code: Alles auswählen

#!/bin/bash

echo $PWD
pkexec 2>/dev/null env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true PWD=$PWD echo $PWD

und ich rufe es aus /etc heraus auf

Code: Alles auswählen

rolf@ulidor:/etc $ kate_r
/etc
/etc

echo wird als root aufgerufen und gibt das passende Verzeichnis aus. Ersetze ich aber „echo $PWD" durch „kate", dann hat kate /root als Arbeitsverzeichnis voreingestellt. Warum ist das so?

Wie bekomme ich es hin, dass das als root aufgerufene Programm das Arbeitsverzeichnis der aufrufenden Umgebung bekommt?

[detix]

Du kannst dir aber auch einige Schreibarbeiten für pkexec ersparen wenn du das so machst:
viewtopic.php?p=1189357#p1189357

[Ulidor]

Du kannst dir aber auch einige Schreibarbeiten für pkexec ersparen wenn du das so machst:
viewtopic.php?p=1189357#p1189357

Danke für den Hinweis, das hört sich interessant an!
Wie ist das denn bei wheel, wenn du damit als root kate aufrufst, bekommt kate dann das Arbeitsverzeichnis der aufrufenden Umgebung?

[willy4711]

Ich finde das alles ziemlich kompliziert.

Ich hab mir das so gemacht (KDE):

Mouspad installiert (sehr wenig Abhängigkeiten)

Starter, um Dolpin als Root zu starten
Kommando:

Code: Alles auswählen

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true dolphin

Starter um Mousepad als Root starten
Kommando:

Code: Alles auswählen

pkexec mousepad

Wenn ich Dolphin als Root starte, kann eh mit Kate / Kwrite alles als Root öffnen / Editieren.
Sollte ich mit normalen Dolphin unterwegs sein, kann ich die Datei über das Kontex-Menü als Root mit Mousepad editieren.


Policy für Mousepad erschaffen:

Code: Alles auswählen

cat /usr/share/polkit-1/actions/org.xfce.mousepad.policy
<?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>

 <vendor>Mousepad</vendor>
 <vendor_url>http://xfce.org/</vendor_url>
 <icon_name>accessories-text-editor</icon_name>

 <action id="org.xfce.mousepad">
 
 <description>Run Mousepad as root</description>
 <description xml:lang="de">Mousepad als Systemverwalter ausführen</description>
 <description xml:lang="en_AU">Run Mousepad as root</description>
 <message xml:lang="de">Authentifizierung notwendig, um Mousepad als Systemverwalter auszuführen.</message>
 <message xml:lang="en_AU">Authentication is required to run Mousepad as root.</message>
 <defaults>
 <allow_any>no</allow_any>
 <allow_inactive>auth_admin</allow_inactive>
 <allow_active>auth_admin</allow_active>
 </defaults>
 <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/mousepad</annotate>
 <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
 </action>

</policyconfig>

Alle anderen Programme, die man eventuell als Root braucht, lassen sich eh aus dem Menü aufrufen.

[detix]

Wie ist das denn bei wheel, wenn du damit als root kate aufrufst, bekommt kate dann das Arbeitsverzeichnis der aufrufenden Umgebung?

bin mir nicht sicher was du meinst...
wenn ich zB krusader als root aufrufe, dort eine Datei zum Bearbeiten mit kate auswähle und die unter einem anderem Namen speichern will, so wird mir zuerst auch das Verzeichnis dieser Datei als Speicherort angeboten.

@willy4711: pkexec ist unnötig kompliziert...

[Ulidor]

bin mir nicht sicher was du meinst...

Was passiert, wenn du als normaler User in einer Shell z.B. im Verzeichnis /etc bist und das hier aufrufst:

Code: Alles auswählen

su - -c kate

Wenn du dann in kate auf „Speichern unter..." gehst, ist der sich öffnende Dateirequester dann in /etc?

Rufe ich mein Skript z.B. so auf

Code: Alles auswählen

rolf@ulidor:/etc $ kate_r fstab

dann wird kate als root mit einer leeren Datei namens fstab gestartet, die beim Speichern in /root landen würde.

@willy4711: Mir geht es darum, dass kate, wenn es aus meinem Skript mit pkexec aufgerufen wird, sich genauso verhalten soll, wie wenn kate direkt aufgerufen wird, nur dass es dann eben als root läuft. Das macht es aber nicht. Ich habe auch ein Skript für dolphin angelegt. Da spielt das mit den Verzeichnissen keine Rolle, weil dolphin beim Öffnen sowieso im darin eingestellten Verzeichnis ist.
Das mit dem Skript für kate ist also eher ein kleines Problem. Aber ich möchte kate auch als normaler User aus einer Shell oder als normaler User im Kontextmenü von dolphin heraus mit root-Rechten aufrufen können.

[willy4711]

Ich weiß nicht, was du genau willst. Ich rede hier über die Möglichkeit in der GUI eine Datei als Root zu bearbeiten.
Kannst natürlich auch den Bandwurm im Terminal eingeben

Ich habe die folgende Möglichkeiten genannt:

Einen Texteditor (Mousepad) über eine Policy und Starter als Root zu bearbeiten.

Dolphin als Root über einen Starter als Root auszuführen

Das Gleiche Kannst du mit Kate machen:
Starter :

Code: Alles auswählen

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true kate

Sieht dann so aus:

Warum du das unbedingt mit einem Skript machen willst ? Keine Ahnung, bringt auch keinerlei Vorteil.

[detix]

Was passiert, wenn du als normaler User in einer Shell z.B. im Verzeichnis /etc bist und das hier aufrufst:

Code: Alles auswählen

su - -c kate

Wenn du dann in kate auf „Speichern unter..." gehst, ist der sich öffnende Dateirequester dann in /etc?

es gibt eine Fehlermeldung das eine Datei „etc” nicht gespeichert werden kann, aber umbenannt würde sie dennoch in /etc gespeichert

Rufe ich mein Skript z.B. so auf

Code: Alles auswählen

rolf@ulidor:/etc $ kate_r fstab

dann wird kate als root mit einer leeren Datei namens fstab gestartet, die beim Speichern in /root landen würde.

ein:

Code: Alles auswählen

su - -c kate fstab

funktioniert nicht (Fehler: fstab ist nicht vorhanden), aber ein

Code: Alles auswählen

su - -c "kate fstab"

funktioniert...

Edith: su - -c "kate fstab" öffnet nicht die fstab (leere Datei), su -c "kate fstab" öffnet sie, verbleiben aber weiterhin in /etc

[Ulidor]

Was passiert, wenn du als normaler User in einer Shell z.B. im Verzeichnis /etc bist und das hier aufrufst:

Code: Alles auswählen

su - -c kate

Wenn du dann in kate auf „Speichern unter..." gehst, ist der sich öffnende Dateirequester dann in /etc?

es gibt eine Fehlermeldung das eine Datei „etc” nicht gespeichert werden kann, aber umbenannt würde sie dennoch in /etc gespeichert

Das verstehe ich nicht. /etc ist doch das Verzeichnis, von dem aus das Skript aufgerufen wird. „etc" taucht ja nirgendwo als Dateiname auf.

Code: Alles auswählen

su - -c kate fstab

funktioniert nicht (Fehler: fstab ist nicht vorhanden), aber ein

Code: Alles auswählen

su - -c "kate fstab"

funktioniert...

su erwartet hinter -c nur einen Token, deshalb muss ein Befehl/Befehlskette mit Optionen/Argumenten in Anführungszeichen stehen. Okay, wenn es funktioniert, werde ich das mal ausprobieren!

[detix]

Das verstehe ich nicht. /etc ist doch das Verzeichnis, von dem aus das Skript aufgerufen wird. „etc" taucht ja nirgendwo als Dateiname auf.

Ich verstehs auch nicht ist aber leider so, Bug?
Ist auch nicht anders wenn du mit „su -c 'kate fstab'” versuchst die Datei so zu speichern, das Umbenennen funktioniert und das Überschreiben geht auf Nachfrage auch!

[Ulidor]

@detix:
Ich bin jetzt deiner Anweisung aus dem Link deines ersten Postings gefolgt und habe die Datei /etc/pam.d/su verändert. Da es mir aber nur darum geht, GUI-Programme als root auszuführen, habe ich der Datei nur die Zeile „session optional pam_xauth.so" hinzugefügt. Und zwar bei einem in einer VM laufenden Bullseye.

Wenn ich

Code: Alles auswählen

$ su -c kate

eingebe, wird kate zwar als root gestartet und ist auch im richigen Verzeichnis, aber es hagelt Fehlermeldungen, u.a. von Pulseaudio (warum auch immer).

Starte ich kate mit

Code: Alles auswählen

$ su - -c kate

läuft das Programm zwar einwandfrei, es ist aber im Verzeichnis /root. Was in dem Fall auch nicht verwunderlich ist, denn in der Manpage zu su steht bei der Option „-" unter anderem: „wechselt in das Home-Verzeichnis des Zielbenutzers."

Also bei meinem ursprünglichen Problem hilft es zwar nicht, aber immerhin kann ich damit von der Kommandozeile aus ohne viel Getippe jedes GUI-Programm als root aufrufen. Das werde ich dann auch für mein Arbeitssystem mit Buster übernehmen.

[detix]

Ein wenig weiter...
Die Problematik scheint beim Pfad zu den Qt-Dateien zu liegen (Ausgaben verkürzt):

Code: Alles auswählen

su -c 'echo $PWD; kate /etc/fstab'
/etc
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0

obige Meldung ist uninteressant, beim „Speichern unter” gibt es dann aber diese Fehlermeldung:

Erstellung des Ein-/Ausgabemoduls nicht möglich. Socket für Ein-/Ausgabemodul für „file“ kann nicht gestartet werden.

in der Konsole steht:

kf5.kio.core: KIO Connection server not listening, could not connect
kf5.kio.core: couldn't create slave: "Socket für Ein-/Ausgabemodul für „file“ kann nicht gestartet werden."

anders siehts aus mit:

Code: Alles auswählen

su - -c 'echo $PWD; kate /etc/fstab'
/root
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: Got EXEC_NEW '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'

hier wird mir beim „Speichern unter” das Verzeichnis dieser Datei und auch dessen Name vorgeschlagen, ohne beachtenswerte Fehlermeldung! Was sonst noch an Meldungen in der Konsole steht ist uninteressant.
Wenn du sowas aus einem Skript heraus ausführen möchtest wäre mein Vorschlag der Umweg über eine Variable, zB:

Code: Alles auswählen

x=/etc/fstab; su - -c "kate $x" # direktes Öffnen
x=/usr/share/plasma; su - -c "cd $x; kate" # leere Datei dort speichern

Der Inhalt für x sollte sich im Skript doch vorbereiten lassen...

[Ulidor]

Diese Fehlermeldungen habe ich auch bekommen.

Der Inhalt für x sollte sich im Skript doch vorbereiten lassen...

Ja, aber erst mal muss der Inhalt ohne mein Zutun in das Skript reinkommen. Z.B. wenn ich es aus einem Kontextmenü heraus aufrufe.
Das mit cd ist wohl schon ein guter Ansatz. Ich hatte es ja mit $PWD versucht. Allerdings wird $PWD zwar vom System gesetzt, aber nicht gelesen, um das Arbeitsverzeichnis zu setzen. Dafür ist ja cd zuständig.

Wenn das so kompliziert ist, ist das den Aufwand vielleicht gar nicht wert. Zwar muss ich kate ab und zu als root aufrufen. Aber eigentlich hat willy4711 schon recht, meistens reicht es, wenn ich das aus einem als root laufenden Dolphin heraus mache.

[willy4711]

Wenn das so kompliziert ist, ist das den Aufwand vielleicht gar nicht wert. Zwar muss ich kate ab und zu als root aufrufen.

Kannst du doch problemlos auch als normaler User wenn du es machst, wie ich oben vorgeschlagen habe.
Einfach einen Starter erstellen:
KDE-Menü--->Menüeinträge bearbeiten (falls dieser Eintrag nicht vorhanden kmenuedit)
Dann suchst du dir aus, wo es hin soll (z.B. Dienstprogramme) -->Neues Element, gibst den Befehl ein

Code: Alles auswählen

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY KDE_SESSION_VERSION=5 KDE_FULL_SESSION=true kate

nettes Icon auswählen
speichern.
Alles andere (erstellen der Desktop-Datei) geschieht dann automatisch nach ~/.local/share/applications/Kate als Root.desktop
Das erste mal musst du dann im Dolphin Kontex-Menü (öffnen mit) deinem "Kate als Root" suchen und Dolphin sagen, er soll sich das merken.
Dolphin erstellt dann unter ~/.config/menus/applications-kmenuedit.menu einen neuen Menü-Eintrag.
Für immer Ruhe, und das was du willst

[Ulidor]

@willy4711

Ich habe da mein eigenes Konzept. Z.B. mag ich es nicht, komplizierte Sachen direkt ins KDE-Menü einzutragen. Sollte ich aus irgendwelchen Gründen das System neu einrichten müssen, fängt die Sucherei an, wo das KDE-Menü überhaupt seine Daten speichert. Ich rufe bei komplizierter Sachen statt dessen ein Skript aus dem KDE-Menü heraus auf. Da weiß ich, wo das liegt und würde das bei einer Neueinrichtung einfach aus dem Backup holen, einen kurzen Eintrag ins KDE-Menü einfügen, fertig.
Das kann ja jeder handhaben, wie er möchte. Ich bleibe bei meinem Konzept.

Aber das alles hat ja nichts mit meinem Problem zu tun. Auch wenn es eher ein Problemchen ist.