udev rule to lock session on removal of hid key

Question

I am trying to lock the session on removal of my hid device which is HyperFIDO U2F key. However after trying for many times I got no success.

I tried to create a udev rule on /etc/udev/rules.d/50-lockscreen.rules which looks like this:

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

The script that it calls to, lock.sh looks like this:

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

Can anyone help me?

Answer 1

Let's assume you are on a distribution that uses systemd. If so ...

Look at this page to get information on how to get the key device info to put into the rule so that it matches the particular event associated with the removal (there will be several) and then in the RUN part of the rule put /usr/bin/loginctl lock-sessions. Reload the udev rules, pull out your key and your screen will lock and so will all sessions on that machine.

To lock one session you will have to find your particular session ID and lock only that one but if you have root you probably have that entire machine to yourself. Locking all sessions is not a problem in most cases.

And you are done.

Answer 2

The most likely explanation is that gnome-screensaver-command, when run in the context udev provides, has no idea whose screensaver on which display it is supposed to command - it is not running under your user account, and it does not have the environment variables that are propagated throughout your X user session.

An approach that can likely be made to work:

• run gnome-screensaver-command under a su to your user
• make sure that the DISPLAY environment variable is set to the same value it has in a terminal within your X session
• make sure that connection authority to your X session is established - this will need some fiddling with xauth and/or xhost, details very dependent on your exact setup

To explain the problem in more detail: X11, which gnome uses as its infrastructure, allows for scenarios like "multiple independent sessions, which might be all have different user accounts logged in, switchable via function keys or wired to different monitors and mice/keyboards" ("Multiseat") and "the actual session is running on a different machine than the one the monitor and HID devices are attached to" ("XDMCP" is the keyword here). "One session, one user" is actually just one possible use case, and the only one in which a command interfering with anything in such a session without being part of it could know how to react correctly - but there are no special provisions built in for that case.

Answer 3

The manpage says:

 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.

So you can't do this in an udev-rule. But you can use an udev rule to communicate with another program that you start when you login, which will then turn on the screensaver. This also solves the problem of giving that program the correct DISPLAY, authority cookies etc.

It also solves the problem of what should happen if more than one user is logged in and using X (physically if there are several screens, or remotely), because X is explictely written to allow this, even if many people don't know and don't use this feature.