
Я пытаюсь заблокировать сессию при удалении моего скрытого устройства, которым является ключ 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 явно написан так, чтобы это разрешать, даже если многие люди не знают и не используют эту функцию.