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

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

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

Источник

3 ответа

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

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

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

И все готово.

Источник

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

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

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

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

Источник

На странице написано:

 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 для связи с другой программой, которую вы запускаете при входе в систему, которая затем включает заставку. Это также решает проблему предоставления этой программе правильного ОТОБРАЖЕНИЯ, авторизованных файлов cookie и т. Д.

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

Источник
Другие вопросы по тегам