Clarification on xss-lock configuration

[jrmd54]

Hello,

I have the current configuration in my i3/config file:

exec_always --no-startup-id xss-lock --transfer-sleep-lock -l -- i3lock --nofork
bindsym $alt+Shift+Delete exec --no-startup-id loginctl lock-session && systemctl suspend

I recently ran into the issue where, when using my shortcut to suspend my session, i3lock failed to grab the keyboard but xss-lock still ran suspend.

I.e. when resuming my session, there was no lock screen.

I tried many solutions and other lockers, but in the end the only one that seem to work for me was to use my own fork of xss-lock as described in issue 311.

Is there really no other solution? If so, shouldn't this workaround with xss-lock be explicitly written in the README?
The fact that the base xss-lock binary can suspend without i3lock actually grabbing the lock seems like a huge security issue to me.

[stapelberg]

bindsym $alt+Shift+Delete exec --no-startup-id loginctl lock-session && systemctl suspend

Can you try adding the --release flag after bindsym? See https://i3wm.org/docs/userguide.html#keybindings

The main reason why i3lock would fail to grab the keyboard/mouse is because they are still grabbed as part of processing the keyboard shortcut.

With --release, hopefully you’ll not run into this again.

---

Is there really no other solution? If so, shouldn't this workaround with xss-lock be explicitly written in the README?

I’m not aware of a solution for this problem, at least when using xss-lock as-is.

I suppose one solution would be to move XSS integration into i3lock itself, which would give us more control. I haven’t checked if the XSS protocol would allow us to prevent suspend if i3lock fails, though.

[jrmd54]

Unfortunately --release does not seem to affect the grab issue here.
What is worse is that I ran again into an unlocked session after waking from suspend despite using the forked xss-lock binary.
I am trying xsecurelock to see if I reproduce the issue.

[jrmd54]

Hum I ran into the same problem with xsecurelock.

My current fix is to not use xss-lock and replace my binding to suspend with a script that launch i3lock; then after e.g. 2 minutes if the i3lock process is still running, suspend is called.
This way i can at least visually check if i3lock is successfull when grabbing. (while with xss-lock I do not know if the grab was successful or not until I resume from suspend)

#!/usr/bin/env bash
LOCK_CMD="i3lock --nofork"
SLEEP_CMD="systemctl suspend"
TIMEOUT=1200
CHECK_INTERVAL=1

$LOCK_CMD &
lock_pid=$!

elapsed=0
while true; do
    if ! kill -0 "$lock_pid" 2>/dev/null; then
        exit 0
    fi
    (( elapsed += CHECK_INTERVAL ))
    if (( elapsed % TIMEOUT == 0 )); then
        $SLEEP_CMD
    fi
    sleep "$CHECK_INTERVAL"
done