Many screen lockers (mine is i3lock) do not block access to other Virtual Terminals. This means that, if I leave a session opened in some VT, then even when the desktop is locked (for example when resuming), a malicious person can switch to the VT and do anything.

This is an actual issue for me, as I occasionally switch to a VT, then switch back to the graphical environment and forget to log out from the VT.

The question then is: how to add VT-locking on top of an existing screen locker?

The Arch Linux wiki suggests to simply disable VTs from Xorg, with this piece of configuration for the X server:

Section "ServerFlags"
    # disable VT switching:
    Option "DontVTSwitch" "True"
    # disable “zapping”, ie. killing the X server with Ctrl-Alt-Bksp:
    Option "DontZap"      "True"

This is not an option since I use VTs, as already explained above. Maybe one solution would be to set and reset those options dynamically, but I found nothing to change X server options at runtime, at least in general (there are things like setxkbmap for keyboard layouts, or xset for misc stuff). Is this possible?

I also found the command vlock -a which, when called from a text-based VT, locks the session and disable VT switching. However, it does not work from the graphical environment, and would anyway be redundant with the graphical screen locker.

How can I solve this problem?


Using vlock with a delay worked for me. I had X server already running, switched to VT-1 with Ctrl-Alt-F1, ran sleep 3; vlock -a, then switched back to VT-7 with Alt-F7. The first time, I didn't switch back to VT-7 fast enough and had to unlock and try again. I got it the second try, and X appears and works like normal. Attempting to switch back to VT-1 presents a locked terminal which you can't switch out of until you unlock it. Don't try to background vlock - I got an endless loop of messages until I exited that session. Maybe putting just vlock -a in custom startx script which executes /usr/bin/startx after would work for automating it. I'm thinking including the delay in the script wouldn't help unless it could run in parallel or backgrounded (not sure I would want to try that again with vlock).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.