Keepassxc: Lock database on SessionLock does not work with i3lock on arch linux

[kiprasmel]

Expected Behavior

I'd expect the database to lock when my screen gets locked.

Current Behavior

The database is not locked on screen lock and after unlocking the screen - the database is still unlocked.

Possible Solution

Lock the database on lock screen (https://github.com/keepassxreboot/keepassxc/pull/545)

Steps to Reproduce

1. Use arch linux
2. Use i3 (i3gaps)
3. Unlock your database
4. Use i3lock to lock your screen

$ i3lock

1. Unlock your screen
2. Database is still unlocked.

Context

I'm running on arch linux, using i3 (i3gaps) as my window manager, and i3lock as my screen locker.
I expect my database to get locked once I lock my screen, but the database does NOT get locked.

Debug Info

KeePassXC - Version 2.4.3
Revision: 5d6ef0c

Qt 5.12.4
Debugging mode is disabled.

Operating system: Arch Linux
CPU architecture: x86_64
Kernel: linux 5.1.15-arch1-1-ARCH

Enabled extensions:
- Auto-Type
- Browser Integration
- SSH Agent
- KeeShare (signed and unsigned sharing)
- YubiKey

Cryptographic libraries:
 libgcrypt 1.8.4

---

Or is it expected behavior that on screen lock the database locks, but on screen unlock it unlocks itself?

---

Edit: I've created an issue for i3lock.

[droidmonkey]

I just looked through the i3 documentation and i3lock source code and couldn't find anything regarding an event notification that is sent out when the screen is locked. I do not think this is even possible. Please bring this up with the i3 developers.

[chron-isch]

sway and swaylock have the same problem, but even when using 'loginctl lock-session' (which uses DBUS as far as I know) KeepassXC doesn't lock it's database.

[relaxeaza]

LightDM lock functionality dm-tool lock is not detected also.

[DuBistKomisch]

In the meantime, you can use the KeePassXC D-Bus interface to lock the database as explained here: https://github.com/keepassxreboot/keepassxc/issues/2764#issuecomment-495713251.

Looking at ScreenLockListenerDBus, you should be able to lock the session in logind and have KeePassXC notice, but no matter how I do it the database doesn't lock (loginctl lock-session, various qdbus commands to org.freedesktop.login1).

Maybe the real problem is that we're not running a display manager, just startx? I know teamviewer has issues in similar cases for example.

[afflux]

I see this dbus signal when locking my session using xss-lock:

sender=:1.29 -> destination=(null destination) serial=211 path=/org/freedesktop/login1/session/_33; interface=org.freedesktop.login1.Session; member=Lock

ScreenLockListenerDBus builds the listening path using /org/freedesktop/login1/session/$XDG_SESSION_ID, but my XDG_SESSION_ID is 3, while the signal appears on a path ending with /_33

[afflux]

Turns out, there are ways to get the current session object:

$ gdbus  call --system --dest org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.GetSession "$XDG_SESSION_ID"
(objectpath '/org/freedesktop/login1/session/_33',)

(introduced in systemd/systemd@bef422ae1e7cbe77ad72dcbfe44798b0fe5e2931, systemd v30)

note that you could also use the self session /org/freedesktop/login1/session/self that will always resolve to the session of the caller, but I couldn't get the signal connection to work here, so I'm not sure if that helps. It was introduced in systemd/systemd@927b1649448b812a7620ad013f4752d597b12407, systemd v209.

[DuBistKomisch]

switching from raw i3lock ... to xss-lock -- i3lock -n ... is working for me with #4214 :+1: thanks @afflux