udev-Regel zum Sperren der Sitzung beim Entfernen des versteckten Schlüssels

449
dkbhadeshiya

Ich versuche, die Sitzung beim Entfernen meines verborgenen Geräts (HyperFIDO U2F-Schlüssel) zu sperren. Nach vielen Versuchen hatte ich jedoch keinen Erfolg.

Ich habe versucht, eine Udev-Regel zu erstellen, /etc/udev/rules.d/50-lockscreen.rulesdie wie folgt aussieht:

SUBSYSTEM="hid", ACTION=="remove", RUN+="/usr/local/bin/lock.sh"

Das Skript, zu dem es aufgerufen wird, lock.shsieht folgendermaßen aus:

#!/bin/bash /usr/bin/gnome-screensaver-command --lock

Kann mir jemand helfen?

1

2 Antworten auf die Frage

0
rackandboneman

Die wahrscheinlichste Erklärung ist, dass gnome-screensaver-command, wenn es in dem von udev bereitgestellten Kontext ausgeführt wird, keine Ahnung hat, wessen Bildschirmschoner auf welcher Anzeige es steuern soll - es wird nicht unter Ihrem Benutzerkonto ausgeführt und verfügt nicht über die Umgebung Variablen, die während Ihrer X-Benutzersitzung verbreitet werden.

Ein Ansatz, der wahrscheinlich funktionieren kann:

  • Führen Sie gnome-screensaver-command unter einem su für Ihren Benutzer aus
  • Stellen Sie sicher, dass die Umgebungsvariable DISPLAY auf den gleichen Wert wie in einem Terminal Ihrer X-Sitzung gesetzt ist
  • Stellen Sie sicher, dass die Verbindungsautorität für Ihre X-Sitzung eingerichtet ist. Dies erfordert einige Spielereien mit xauth und / oder xhost. Die Details hängen sehr von Ihrem genauen Setup ab

Um das Problem genauer zu erläutern: X11, das gnome als Infrastruktur verwendet, ermöglicht Szenarien wie "mehrere unabhängige Sitzungen, bei denen möglicherweise unterschiedliche Benutzerkonten angemeldet sind, die über Funktionstasten umschaltbar sind oder mit verschiedenen Monitoren und Mäusen / Tastaturen verkabelt sind "(" Multiseat ") und" die eigentliche Sitzung läuft auf einem anderen Rechner als dem, an den Monitor und HID-Geräte angeschlossen sind "(" XDMCP "ist hier das Schlüsselwort). "Eine Sitzung, ein Benutzer" ist eigentlich nur ein möglicher Anwendungsfall, und der einzige, in dem ein Befehl, der in einer solchen Sitzung irgendetwas stört, ohne Teil davon zu sein, richtig reagieren kann - es sind jedoch keine besonderen Vorkehrungen eingebaut für diesen Fall.

0
dirkt

Die Manpage sagt:

 RUN ... This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device.  Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished.

Das kann man also nicht in einer Udev-Regel tun. Sie können jedoch eine udev-Regel verwenden, um mit einem anderen Programm zu kommunizieren, das Sie beim Anmelden starten, wodurch der Bildschirmschoner aktiviert wird. Dies löst auch das Problem, dass das Programm das korrekte DISPLAY, Berechtigungscookies usw. erhält.

Es löst auch das Problem, was passieren soll, wenn mehrere Benutzer angemeldet sind und X verwenden (physisch, wenn mehrere Bildschirme vorhanden sind oder aus der Ferne), da X explizit geschrieben wird, um dies zuzulassen, auch wenn viele Benutzer und nicht kennen Verwenden Sie diese Funktion nicht.

Verwandte Probleme