Правило udev для блокировки сеанса при удалении скрытого ключа

Правило udev для блокировки сеанса при удалении скрытого ключа

Я пытаюсь заблокировать сессию при удалении моего скрытого устройства, которым является ключ HyperFIDO U2F. Однако после многочисленных попыток я не добился успеха.

Я попытался создать правило udev, /etc/udev/rules.d/50-lockscreen.rulesкоторое выглядит следующим образом:

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

Скрипт, к которому он обращается, lock.shвыглядит так:

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

Может кто-нибудь мне помочь?

решение1

Предположим, что вы используете дистрибутив, использующий systemd. Если так...

Посмотри на этостраницачтобы получить информацию о том, как получить информацию об устройстве ключа для помещения в правило, чтобы оно соответствовало конкретному событию, связанному с удалением (их будет несколько), а затем в части RUN правила поместите /usr/bin/loginctl lock-sessions. Перезагрузите правила udev, вытащите ключ, и ваш экран заблокируется, как и все сеансы на этой машине.

Закрыватьодинсеанс вам придется найти свой конкретный идентификатор сеанса и заблокировать только его, но если у вас есть root, то, вероятно, вся машина будет в вашем распоряжении. Блокировка всех сеансов не является проблемой в большинстве случаев.

И все готово.

решение2

Наиболее вероятным объяснением является то, что gnome-screensaver-command при запуске в контексте, предоставляемом udev, не имеет ни малейшего представлениячейзаставка включенакакой дисплейон должен выполнять команды — он не запускается под вашей учетной записью пользователя и не имеет переменных среды, которые распространяются на весь сеанс вашего пользователя X.

Подход, который можетвероятныйбыть вынуждены работать:

  • запустите gnome-screensaver-command под учетной записью su для вашего пользователя
  • убедитесь, что переменная окружения DISPLAY имеет то же значение, что и в терминале в сеансе X
  • убедитесь, что установлены полномочия на подключение к вашему сеансу X — для этого потребуется немного повозиться с xauth и/или xhost, детали сильно зависят от ваших точных настроек

Чтобы объяснить проблему более подробно: X11, который gnome использует в качестве своей инфраструктуры, допускает такие сценарии, как «несколько независимых сеансов, в которых могут быть зарегистрированы разные учетные записи пользователей, переключаемые с помощью функциональных клавиш или подключенные к разным мониторам и мышам/клавиатурам» («Multiseat») и «фактический сеанс запущен на другой машине, нежели та, к которой подключены монитор и HID-устройства» («XDMCP» здесь ключевое слово). «Один сеанс, один пользователь» на самом деле является лишь одним из возможных вариантов использования, и единственным, в котором команда, вмешивающаяся в что-либо в таком сеансе, не являясь его частью, может знать, как правильно реагировать, но для этого случая нет никаких специальных встроенных положений.

решение3

На странице руководства написано:

 RUN{type}
      ...
      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.

Так что вы не можете сделать это в udev-правиле. Но вы можете использовать правило udev для связи с другой программой, которую вы запускаете при входе в систему, которая затем включит заставку. Это также решает проблему предоставления этой программе правильного DISPLAY, авторизационных куки и т. д.

Это также решает проблему того, что должно произойти, если в систему вошли более одного пользователя и используют X (физически, если есть несколько экранов, или удаленно), поскольку X явно написан так, чтобы это разрешать, даже если многие люди не знают и не используют эту функцию.

Связанный контент