[gelöst] modprobe mit pkexec

[avDeb]

Guten Tag,

ich würde gerne eine Gnome-Shell Extension verwenden, die

Code: Alles auswählen

pkexec --user root modprobe -av uvcvideo

bzw.

Code: Alles auswählen

pkexec --user root modprobe -rv uvcvideo

verwendet, um das Kernel-Modul ein- und auszuladen.

Nur funktioniert pkexec bei mir für modprobe nicht:
Cannot run program modprobe: No such file or directory


Kennt jemand eine Lösung, um das zum Laufen zu bringen?

[smutbert]

Ändert sich etwas, wenn du den kompletten Pfad (/usr/sbin/modprobe) angibst?

[avDeb]

Ändert sich etwas, wenn du den kompletten Pfad (/usr/sbin/modprobe) angibst?

Nein.

[debianoli]

Ist so was für Root unter Gnome tatsächlich vorgesehen? Für mich wäre es eine dicke Sicherheitslücke, wenn ein normaler User einfach mit einem Skript ohne Probleme mit Root-Rechten rumfuhrwerkt

[smutbert]

Hast du den Pfad auch geprüft?
Ich kenne dein System natürlich nicht, aber möglicherweise ist modprobe bei dir in »/sbin« (ich weiß nicht wo es vor der Zusammenlegung von »/sbin« und »/usr/sbin« war).

@debianoli
policykit/Gnome fragt je nach Konfiguration und Gruppenmitgliedschaft nach einem Passwort oder verweigert direkt die Ausführung.

[debianoli]

@smutbert

Danke für die Info. Kann dann der Fehler nicht eine Folge der lokalen Config von policKit/gnome sein?

[smutbert]

Eher nicht. Die Fehlermeldung deutet doch sehr eindeutig daraufhin, dass modprobe nicht ausgeführt werden kann weil es nicht gefunden wird.

Sonst würde sie eher so lauten

Code: Alles auswählen

==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.

[avDeb]

Hast du den Pfad auch geprüft?
Ich kenne dein System natürlich nicht, aber möglicherweise ist modprobe bei dir in »/sbin« (ich weiß nicht wo es vor der Zusammenlegung von »/sbin« und »/usr/sbin« war).

@debianoli
policykit/Gnome fragt je nach Konfiguration und Gruppenmitgliedschaft nach einem Passwort oder verweigert direkt die Ausführung.

Tatsächlich. modprobe ist bei mir im /sbin und wenn man den Pfad angibt, funktioniert's. Was müsste ich nun machen, dass pkexec auch ohne dem Pfad das Programm findet?

[alexander_ro]

Das kommt darauf an wie das modprobe gestartet wird. Bei einem normalen Aufruf in der Shell ist die Variable PATH dafür zuständig. Das kannst Du so prüfen:

Code: Alles auswählen

export | grep PATH

Wird modprobe von einem anderen Prozess gestartet kann es sein das diese Variable nicht gesetzt ist. Dann musst Du die selber setzen oder beim Aufruf den Pfad mit angeben.

[fischig]

Was wäre denn passiert, wenn er statt pkexec modprobe direkt als root (im Terminal oder auf einer console) gestartet hätte?

[avDeb]

Das kommt darauf an wie das modprobe gestartet wird. Bei einem normalen Aufruf in der Shell ist die Variable PATH dafür zuständig. Das kannst Du so prüfen:

Code: Alles auswählen

export | grep PATH

Wird modprobe von einem anderen Prozess gestartet kann es sein das diese Variable nicht gesetzt ist. Dann musst Du die selber setzen oder beim Aufruf den Pfad mit angeben.

/sbin war im PATH nicht dabei (als root schon, aber als user nicht); hab's nun per

Code: Alles auswählen

export PATH=/sbin:$PATH 

ergänzt. Jetzt funktiert die Sache, wie es funktionieren sollte.

Vielen herzlichen Dank.

[alexander_ro]

Schön wenn es funktioniert. Wenn Du das aber nur so einmal in der Shell aufrufst ist die Einstellung beim Neustart wieder weg. Um es dauerhaft zu bekommen musst Du in Deinem User-Verzeichnis das in die Datei .bashrc eintragen. Soll es für alle User gelten gibt es in /etc auch so eine ähnliche Datei in die man das eintragen kann.

[michaa7]

Wäre das nicht ein fall wo man usrmerge installieren sollte?

[smutbert]

usrmerge wird insofern nichts helfen als weder /sbin noch /usr/sbin im Suchpfad eines normalen Benutzers ist.

@fischig
Naja, dass modprobe direkt als root gestartet, funktioniert ist wohl sicher. Hier geht es aber um eine Gnome Shell Extension, die diese Befehle nutzen will und die würde nur dann als root laufen, wenn man sich grafisch als root anmeldet, was keine gute Idee ist und mit gdm/gnome per default auch gar nicht möglich ist.


Das Setzen von PATH oder allgemeiner Umgebungsvariablen unter Gnome ist zumindest ungewohnt – ich weiß nach diesem Thread hier jedenfalls nicht mit Sicherheit wie man eine Umgebungsvariable für Gnome verlässlich setzen könnte (/etc/profile und ~/.profile werden nur von Login-Shells gelesen, /etc/bash.bashrc und ~/.bashrc nur von der bash, für ~/.pam_environment muss man das zugehöroge pam-Modul aktivieren und das einzige was eigentlich ohne weitere Maßnahmen funktionieren sollte. eine Datei in ~/.config/environment.d/ hat im betreffenden Thread nicht funktioniert).


mir fallen unter den Umständen nur diese 3 Möglichkeiten ein:

1. ein symbolischer Link zu modprobe zB in »/usr/local/bin« oder »~/.local/bin«

   Code: Alles auswählen

   $ mkdir -p ~/.local/bin
   $ ln -s /sbin/modprobe ~/.local/bin/modprobe
   

2. das Anpassen der Extension. Dazu ist nicht einmal notwendig den Quellcode der Extension zu verstehen, es sollte genügen die Stelle zu finden an der pkexec aufgerufen wird und dort modprobe um den Pfad zu ergänzen.
   Die installierten Extensions liegen unter »~/.local/share/gnome-shell/extensions«
3. »/etc/login.defs« editieren und /usr/sbin dort zum Suchpfad für normale Benutzer hinzufügen. Da sollte es bereits diese Zeile geben

   Code: Alles auswählen

   ENV_PATH        PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
   

   die danach etwa so aussehen könnte

   Code: Alles auswählen

   ENV_PATH        PATH=/usr/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
   

[alexander_ro]

Es wäre interessant wo dieser Befehl ausgeführt wurde:

Code: Alles auswählen

export PATH=/sbin:$PATH

Ich kenne jetzt pkexec nicht wirklich. Aber es ist doch ein Shellbefehl der dem Aufrufenden User mehr Rechte geben kann. Vermutlich müssen die Rechte irgendwo konfiguriert werden. Wieso ist das dann von GNOME abhängig. Ein xterm führt beim Aufruf auch die bashrc aus. Vorausgesetzt man benutzt die Bash.

[willy4711]

Die Regeln, was wer mit pkexec ausführen darf werden weitestgehend in

/usr/share/polkit-1/actions/
und
/usr/share/polkit-1/rules.d/

festgelegt.

Erklärungen gibt es hier:
https://www.freedesktop.org/software/po ... kit.8.html

[fischig]

Naja, dass modprobe direkt als root gestartet, funktioniert ist wohl sicher.

Danke für die Info!
So hätte ich das auch erwartet. Aber ich weiß ja nie so recht, wohin die Entwicklungs-„Reise“ so alles gehen mag. Deswegen hatte ich mal vorsorglich gefragt, obwohl's mich ja gar nichts angeht. Bitte den TE um Entschuldigung ob der Einmischung. Mag der geneigte Leser selber weiterdenken.

[smutbert]

Wieso ist das dann von GNOME abhängig. Ein xterm führt beim Aufruf auch die bashrc aus. Vorausgesetzt man benutzt die Bash.

Ja, aber hier wird pkexec nicht aus einer Shell, nicht einmal in einem Terminal sondern von einer Gnome Shell Extension gestartet – da muss also nie eine Bash (oder andere Shell) im Spiel gewesen sein.

[alexander_ro]

nie eine Bash

Man kann nicht einfach ein Programm starten ohne nichts. Irgendwer muss es im Filesystem suchen, Berechtigungen prüfen und in den Speicher laden. Die vereinfachte Version meist ist da eine Shell in irgendeiner Form beteiligt. Klar das könnten die von GNOME alles selber Programmiert haben. Wäre aber doppelt Arbeit ohne echten Nutzen.

Oben stand auch das es so funktioniert hat mit der veränderten PATH Variable. Das heißt dann das die GNOME Shell zumindest auch die PATH Variable kennt und benutzt. Es bleibt halt die Frage an welcher Stelle wurde die PATH Variable verändert.

[avDeb]

Oben stand auch das es so funktioniert hat mit der veränderten PATH Variable. Das heißt dann das die GNOME Shell zumindest auch die PATH Variable kennt und benutzt. Es bleibt halt die Frage an welcher Stelle wurde die PATH Variable verändert.

Ich habe mich geirrt. Ich hatte die Extension umgeschrieben gehabt, was ich vergessen hatte und dachte mir, dass es nun wegen der ergänzten PATH geklappt hat. Mit der frisch installierten Extension geht's also nicht.

Für mich wäre das Problem grundsätzlich mit der 2. Möglichkeit gelöst:

mir fallen unter den Umständen nur diese 3 Möglichkeiten ein:

1. ein symbolischer Link zu modprobe zB in »/usr/local/bin« oder »~/.local/bin«

   Code: Alles auswählen

   $ mkdir -p ~/.local/bin
   $ ln -s /sbin/modprobe ~/.local/bin/modprobe
   

2. das Anpassen der Extension. Dazu ist nicht einmal notwendig den Quellcode der Extension zu verstehen, es sollte genügen die Stelle zu finden an der pkexec aufgerufen wird und dort modprobe um den Pfad zu ergänzen.
   Die installierten Extensions liegen unter »~/.local/share/gnome-shell/extensions«
3. »/etc/login.defs« editieren und /usr/sbin dort zum Suchpfad für normale Benutzer hinzufügen. Da sollte es bereits diese Zeile geben

   Code: Alles auswählen

   ENV_PATH        PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
   

   die danach etwa so aussehen könnte

   Code: Alles auswählen

   ENV_PATH        PATH=/usr/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
   

Die 1. und 3. Möglichkeit brachten keine Resultate. Aus Neugier würde mich trotzdem noch interessieren, ob Gnome-Shell so etwas Ähnliches wie PATH hat.

[alexander_ro]

Ok das Erklärt warum das alles etwas widersprüchlich aussah.

Ich verwende keinen GNOME und kann es deshalb nicht testen. Wenn Du das noch nicht gemacht hast gibt es hier einige Infos wo man die Verschiedenen Einstellungen machen kann. Ist zwar Ubuntu aber es sollte hier ähnlich sein: https://wiki.ubuntuusers.de/Umgebungsvariable/Dateien/.

[smutbert]

Da gibt es viele Varianten, die auch nicht mehr funktionieren, weil sie zB durch die Startskripte der Xorg-Gnome-Sitzung gelesen und jetzt bei wayland ignoriert werden.

Warum gleich zwei meiner Vorschläge daneben gegangen sind ist mir noch nicht ganz klar - bei einem allerdings schon:
In Debian wird (bei Login-Shells) $PATH mittels »/etc/profile« gesetzt bzw. überschrieben. das dürfte der Grund sein, dass mein 3. ins Leere gegangen ist. Dass Gnome auch in der wayland-Variante überhaupt von einer Shell mit einem Shellskript gestartet wird, habe ich nicht vermutet. Ohne alexander_ros Einwand hätte ich das nicht bemerkt.

Jedenfalls bin ich mir jetzt ziemlich sicher, dass du $PATH in der »/etc/profile« oder in »~/.profile« anpassen kannst, damit die Extension ohne weitere Maßnahmen funktioniert. In ersterer kannst du diese Zeilen

Code: Alles auswählen

if [ "$(id -u)" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

so ändern, dass das zweite PATH=..., das ist das für die normalen Benutzer, ebenfalls /usr/sbin (und der Vollständigkeit halber eventuell auch die anderen sbins) enthält – am besten am Anfang der Liste.

Wenn du das dagegen benutzerspezifisch mit der »~/.profile« erledigen willst, genügt es so etwas hineinzuschreiben

Code: Alles auswählen

PATH="/usr/local/sbin:/usr/sbin:/sbin:${PATH}"
export PATH

[willy4711]

Kann bisher nicht sehen, was wie funktioniert hat.
Hätte aber einen Vorschlag, der zumindest funktioniert (hier mit einer für mich unschädlichen Option):

Code: Alles auswählen

~$ pkexec sh -c "/usr/sbin/modprobe -V"
kmod version 28
-ZSTD +XZ -ZLIB +LIBCRYPTO -EXPERIMENTAL

Irgendwelche Pfade (PATH) sind dann unnötig zu setzen, sehe auch nicht ein, warum man das tun sollte.

[smutbert]

In dem Fall, weil der Befehl nicht im Terminal sondern von einer Gnome Shell Extension ausgeführt wird und man dazu (bei jedem Update der Extension von neuem) den Quellcode der Extension anpassen muss.

[willy4711]

In dem Fall, weil der Befehl nicht im Terminal sondern von einer Gnome Shell Extension ausgeführt wird und man dazu (bei jedem Update der Extension von neuem) den Quellcode der Extension anpassen muss.

Vielleicht habe ich das alles Falsch verstanden.
Ich hatte gedacht dass das eine selbst geschriebene Extension ist.
Andersherum: Wenn er den modprobe Befehl in eine Bestehende einfügt, wird er um die händische Korrektur
auch nicht herumkommen.

Aber wie auch immer, ist wohl unwichtig.