☰

regla udev para bloquear la sesión al eliminar la clave oculta

tag-icon • tag-icon linux ubuntu udev u2f
regla udev para bloquear la sesión al eliminar la clave oculta

Estoy intentando bloquear la sesión al retirar mi dispositivo oculto, que es la clave HyperFIDO U2F. Sin embargo, después de intentarlo muchas veces no tuve éxito.

Intenté crear una regla udev /etc/udev/rules.d/50-lockscreen.rulesque se ve así:

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

El script al que llama lock.shse ve así:

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

¿Alguien puede ayudarme?

Respuesta1

Supongamos que está en una distribución que usa systemd. En ese caso ...

Mira estepáginapara obtener información sobre cómo obtener la información clave del dispositivo para incluirla en la regla de modo que coincida con el evento particular asociado con la eliminación (habrá varios) y luego en la parte EJECUTAR de la regla /usr/bin/loginctl lock-sessions. Vuelva a cargar las reglas de udev, saque su clave y su pantalla se bloqueará, al igual que todas las sesiones en esa máquina.

Para bloquearunosesión, tendrá que encontrar su ID de sesión particular y bloquear solo esa, pero si tiene root probablemente tenga toda esa máquina para usted. Bloquear todas las sesiones no es un problema en la mayoría de los casos.

Y ya está.

Respuesta2

La explicación más probable es que el comando gnome-screensaver-command, cuando se ejecuta en el contexto que proporciona udev, no tiene ideacuyosalvapantallas activadoque pantallase supone que es un comando: no se ejecuta en su cuenta de usuario y no tiene las variables de entorno que se propagan a lo largo de su sesión de usuario X.

Un enfoque que puedeprobablehacerse trabajar:

  • ejecute el comando gnome-screensaver-command bajo su para su usuario
  • asegúrese de que la variable de entorno DISPLAY esté configurada en el mismo valor que tiene en una terminal dentro de su sesión X
  • asegúrese de que la autoridad de conexión a su sesión X esté establecida; esto requerirá algunos ajustes con xauth y/o xhost, los detalles dependen mucho de su configuración exacta

Para explicar el problema con más detalle: X11, que gnome utiliza como infraestructura, permite escenarios como "múltiples sesiones independientes, que pueden tener diferentes cuentas de usuario conectadas, conmutables mediante teclas de función o conectadas a diferentes monitores y ratones/teclados". " ("Multiseat") y "la sesión real se ejecuta en una máquina diferente a aquella a la que están conectados el monitor y los dispositivos HID" ("XDMCP" es la palabra clave aquí). "Una sesión, un usuario" es en realidad sólo un caso de uso posible, y el único en el que un comando que interfiere con algo en dicha sesión sin ser parte de ella podría saber cómo reaccionar correctamente, pero no hay disposiciones especiales incorporadas. para ese caso.

Respuesta3

La página de manual dice:

 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.

Entonces no puedes hacer esto en una regla udev. Pero puedes usar una regla udev para comunicarte con otro programa que inicias cuando inicias sesión, que luego activará el protector de pantalla. Esto también resuelve el problema de darle a ese programa la PANTALLA correcta, las cookies de autoridad, etc.

También resuelve el problema de qué debería suceder si más de un usuario inicia sesión y usa X (físicamente si hay varias pantallas, o de forma remota), porque X está escrito explícitamente para permitir esto, incluso si muchas personas no lo saben y No utilices esta función.

información relacionada