
Estou tentando bloquear a sessão ao remover meu dispositivo oculto, que é a chave HyperFIDO U2F. Porém, depois de tentar muitas vezes, não obtive sucesso.
Tentei criar uma regra do udev /etc/udev/rules.d/50-lockscreen.rules
parecida com esta:
SUBSYSTEM="hid", ACTION=="remove", RUN+="/usr/local/bin/lock.sh"
O script que ele chama lock.sh
é assim:
#!/bin/bash
/usr/bin/gnome-screensaver-command --lock
Alguém pode me ajudar?
Responder1
Vamos supor que você esteja em uma distribuição que usa o systemd. Se for assim ...
Veja issopáginapara obter informações sobre como obter as principais informações do dispositivo para colocar na regra para que correspondam ao evento específico associado à remoção (haverá vários) e, em seguida, na parte RUN da regra, coloque /usr/bin/loginctl lock-sessions
. Recarregue as regras do udev, retire sua chave e sua tela será bloqueada, assim como todas as sessões naquela máquina.
Trancarumsessão, você terá que encontrar seu ID de sessão específico e bloquear apenas aquele, mas se você tiver root, provavelmente terá a máquina inteira só para você. Bloquear todas as sessões não é um problema na maioria dos casos.
E você terminou.
Responder2
A explicação mais provável é que o gnome-screensaver-command, quando executado no contexto fornecido pelo udev, não tem ideiacujoprotetor de tela ativadoque exibeele deve comandar - ele não está sendo executado na sua conta de usuário e não possui as variáveis de ambiente que são propagadas durante a sessão do usuário X.
Uma abordagem que podeprovávelser feito para funcionar:
- execute gnome-screensaver-command sob um su para seu usuário
- certifique-se de que a variável de ambiente DISPLAY esteja definida com o mesmo valor que possui em um terminal em sua sessão X
- certifique-se de que a autoridade de conexão para sua sessão X esteja estabelecida - isso exigirá alguns ajustes no xauth e/ou xhost, detalhes que dependem muito da sua configuração exata
Para explicar o problema com mais detalhes: o X11, que o gnome usa como infraestrutura, permite cenários como "múltiplas sessões independentes, que podem ter diferentes contas de usuário logadas, alternáveis por meio de teclas de função ou conectadas a diferentes monitores e mouses/teclados " ("Multiseat") e "a sessão real está sendo executada em uma máquina diferente daquela à qual o monitor e os dispositivos HID estão conectados" ("XDMCP" é a palavra-chave aqui). "Uma sessão, um usuário" é na verdade apenas um caso de uso possível, e o único em que um comando interferindo em qualquer coisa em tal sessão sem fazer parte dela poderia saber como reagir corretamente - mas não há disposições especiais incorporadas para esse caso.
Responder3
A página de manual diz:
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.
Então você não pode fazer isso em uma regra do udev. Mas você pode usar uma regra do udev para se comunicar com outro programa iniciado ao fazer login, que ativará o protetor de tela. Isso também resolve o problema de fornecer a esse programa o DISPLAY correto, cookies de autoridade, etc.
Também resolve o problema do que deve acontecer se mais de um usuário estiver logado e usando o X (fisicamente se houver várias telas, ou remotamente), porque o X é escrito explicitamente para permitir isso, mesmo que muitas pessoas não saibam e não use esse recurso.