Keepassxc: KeepassXC won't lock when I lock my session - Ubuntu Zesty 17.04 / Gnome 3

[Gui13]

KeepassXC won't lock when I lock my session even though I have enabled it in the options.

Expected Behavior

I have clicked the option "Lock databases when session is locked" in the Security panel.
KeepassXC is opened an has his database opened.
I lock my session using Super + L in gnome
When I unlock the session, Keepass has locked the database and asks me the unlock password.

Current Behavior

I have clicked the option "Lock databases when session is locked" in the Security panel.
I lock my session using Super + L in gnome
When I unlock the session, Keepass is still here with the database opened.

Possible Solution

No idea

Steps to Reproduce (for bugs)

See description above.. it is quite simple.

Context

Your Environment

Ubuntu 17.04 Zesty with Gnome 3
KeePassXC v2.2.0 installed with Snap

[magkopian]

I can confirm that on Debian Stable with Gnome 3.22, the database also doesn't lock together with the session. I made sure that the option Lock databases when session is locked or lid is closed is checked, and I also saved the database to be sure.

KeePassXC 2.2.0 is installed from the Debian package, so it appears that the issue is related to Gnome 3. The current version of Gnome on Ubuntu 17.04 appears to be 3.24.

[sainaen]

I've just checked the current master (caa49a8) and the deb package. Both work for me on Debian Sid with Gnome 3.22 (actual version of the package is 3.22.3-3.)

I'm not sure how to debug this, but I don't think Gnome itself causes this. Is it possible that some required lib (or particular version) is present on my machine but missing on yours? Like, something related to D-Bus maybe?

(Turns out you can record your screen even when machine is locked, so I have a proof! 😄)

[magkopian]

I tried this again using a new blank test database this time, and it worked. So the problem seems to appear specifically with old databases, which existed before the upgrade to 2.2.0.

[phoerious]

Can you post the output of dbus-monitor to a paste service of your choice?

[magkopian]

Forget what I said, I found it. The database locks always, but only if I'm careful to not move my mouse after hitting the lock button and let the monitor to turn off. If I move my mouse after clicking the lock button so the monitor stays on after locking, then KeePassXC doesn't lock the database.

[Gui13]

Here is my proof, mag : https://youtu.be/pAwq7gsl3Qs

I'll post my dbus monitor

[Gui13]

Dbus-monitor result here:
https://zerobin.net/?03fa2d43758e3424#A2jT/1TFGBG5Q6TZakAbajksUUelXQ+8hJzA38Vcy/s=

I ran it while keepass was unlocked, then locked the screen, then unlocked. I Ctrl+C right away and copied the result in there.

[Gui13]

I have tried not moving my mouse while locking but it doesn't work on my version.
My database was brand new (imported from CSV directly into a new DB when I installed 2.2.0 yesterday)

[magkopian]

Here is my dbus-monitor output as well in case it helps, when the database locks and when it doesn't lock. As I said, I can reliably make it lock if I let my screen go blank after locking the desktop, or prevent it from locking by moving my mouse and not let the screen turn off. I tried it many times and that was always the case.

[sainaen]

Huh. Yep, if I don't allow my monitor to turn off, there's neither ActiveChanged event from org.freedesktop.ScreenSaver, nor StatusChanged from org.gnome.SessionManager (KeePassXC listens for them to detect locking.) Same thing in logs from @magkopian.

But both are present in your, @Gui13, logs. We probably have two separate issues here.
One thing I noticed in the @Gui13's log, though, is this line:

error time=1498554465.340655
sender=org.freedesktop.DBus -> destination=:1.318
error_name=org.freedesktop.DBus.Error.AccessDenied
reply_serial=547 string "An AppArmor policy prevents this sender from sending this message to this recipient; type="signal",
sender=":1.318" (uid=1000 pid=7742 comm="/usr/lib/gnome-session/gnome-session-binary --sess") 
interface="org.gnome.SessionManager.Presence" member="StatusChanged"
error name="(unset)"
requested_reply="0"
destination="org.freedesktop.DBus" (uid=1000 pid=5080 comm="keepassxc ")"

Here a signal cannot be sent to KeePassXC, it seems. Another issue with the snap package?

[phoerious]

I suppose this is a Gnome bug (and a Snap permission problem @droidmonkey)?

[droidmonkey]

For the snap this is likely related to why launching the browser with dbus fails.

[Gui13]

Anything I can do to help ? This issue is really dangerous and I'm not confident letting my computer go to sleep with the Keypass DB kept open.

[kennwhite]

Seeing same behavior under standalone KeePassXC-2.2.2-2-x86_64.AppImage on stock install Ubuntu 17.10 (no 3rd party pkgs). Lock on timeout works as expected, but database is still open after Super + L screenlock followed by re-login. "Lock databases when session is locked or lid is closed" is selected. Lock on minimize working as expected. Lock on lid close works, though on an X1 Carbon (5th gen) you have to wait about 8 or 9 seconds after shutting the lid until external keyboard confirms full suspend via power down of backlight.

[mikewoudenberg]

Installed as snap (v2.2.2). Also not seeing the locking of the database happening on locking my linux session (Ubuntu 17.10).

In the dbus monitor logs around the time of locking I see:

signal time=1511957995.689926 sender=:1.17 -> destination=(null destination) serial=1684 path=/org/gnome/ScreenSaver; interface=org.gnome.ScreenSaver; member=ActiveChanged
   boolean true

Looking at https://github.com/keepassxreboot/keepassxc/blob/c69a9785895efdb5e83fce12362b6fe3b843a69b/src/core/ScreenLockListenerDBus.cpp it appears there's no listener being registered for the given signal. Is it possible that that is causing the lock trigger not to fire?

[TheZ3ro]

@mikewoudenberg probably yes, we need to register another listener.

Rant Seems that no-one is following standards among gnu/linux DE, why even bother with freedesktop?

[droidmonkey]

Try following this faq to see if that fixes the dbus issue: https://keepassxc.org/docs#faq-appsnap-open-url

[mikewoudenberg]

@droidmonkey I tried, but it doesn't help. The snapd-xdg-open package does interact with DBUS, but only by performing a method call, not by listening for events. I agree with @TheZ3ro that we'll probably need to add another listener, or ubuntu should get it's act together and use the freedesktop conventions

[ioparaskev]

just to report that this feature doesn't work on Fedora 26 either

[TheZ3ro]

@ioparaskev wich DE are you using? KDE?

[ioparaskev]

@TheZ3ro I'm using awesome-wm but I can try to see if it works in GNOME only. I don't have KDE installed

[TheZ3ro]

@ioparaskev try run this command dbus-monitor --session "type='signal'" > log.txt and see if there are some ScreenSaver related signal in the log.txt file

[ioparaskev]

@TheZ3ro you are right, there are not signals emitted. This is because I'm using i3lock with xautolock as a screensaver & lock. I don't really care about the screensaver thing, but I've noticed the feature doesn't work on lid closing. When referring to lid closing, do we mean suspend or simply the action of a closing lid?

[TheZ3ro]

@ioparaskev normally it's suspending, but if closing the lid emit a signal we can listen to that as well. Sadly we can't do anything if there are no emitted dbus signals

[ioparaskev]

@TheZ3ro you are right, I checked and it seem that in Fedora there's no dbus signal when going to sleep. So I guess there's no way to have this feature :/

[TheZ3ro]

@ioparaskev maybe there is an option to send dbus signals in i3 or xautolock

[TheZ3ro]

1249 is merged in develop. Gnome should now work fine. Remember to enable the screen-saver option otherwise the signal won't be delivered.

Also for the snap we have this policy problem: An AppArmor policy prevents this sender from sending this message to this recipient

error time=1498554472.734438 sender=org.freedesktop.DBus -> destination=:1.318 error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=550 string "An AppArmor policy prevents this sender from sending this message to this recipient; type="signal", sender=":1.318" (uid=1000 pid=7742 comm="/usr/lib/gnome-session/gnome-session-binary --sess") interface="org.gnome.SessionManager.Presence" member="StatusChanged" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (uid=1000 pid=5080 comm="keepassxc ")"

[ioparaskev]

@TheZ3ro in i3lock there surely isn't:
I will check to see if I can send one for the closing lid event. I have a systemd job that gets triggered when the lid closes so maybe I can trigger a send on my one for this case. Can you describe what kind of dbus message keepassxc is listening for?

[TheZ3ro]

@ioparaskev This command will lock keepassxc qdbus org.freedesktop.ScreenSaver /ScreenSaver SetActive true
Alternatively you can use this (will also lock the DE session) qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock

[phoerious]

I doubt we can support all window managers. We should support the three/four big desktop environments. The rest should either adhere to freedesktop standards or not complain.

[ioparaskev]

I agree with @phoerious but maybe an different way of "supporting" everyone could be found. For example a mechanism to support specific custom messages to lock the database without depending on which WM/DE someone has (of course the current support should also keep existing).
I'm thinking for something like this:
qdbus com.keepasslxc.session /db "lock" to trigger the immediate locking of the database.
That's what I was asking for @TheZ3ro because currently I don't have any of the classic screensavers running (gnome/kde/freedesktop)

[TheZ3ro]

@ioparaskev the qdbus command will query the dbus service keepassxc is listening on. The freedesktop query I reported above it's standard and should work on every system (doesn't require a screensaver running, it's just a dbus service)

[ioparaskev]

no it doesn't :stuck_out_tongue:

qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
Service 'org.freedesktop.ScreenSaver' does not exist.

[grimpy]

@ioparaskev same here for now I have this ugly workaround.
I enabled the option to lock when minimizing the app and use wmctrl -x -r keepassxc -b add,hidden to minimize the app from a script

[hasufell]

@grimpy even that doesn't work for me on i3

I doubt we can support all window managers.

As has been said before. You don't need to. Support a method anyone can use to trigger locking of the database via a command.

[TheZ3ro]

I will include a dbus service for locking. I hope every GNU/linux service supprt dbus :D

[hasufell]

I will include a dbus service for locking. I hope every GNU/linux service supprt dbus :D

So, how do you use this? The README was removed. Now what?

Literally none of the suggestions above (including wmctrl) work.

[ioparaskev]

@hasufell
qdbus org.keepassxc.KeePassXC.MainWindow /keepassxc org.keepassxc.MainWindow.lockAllDatabases
works fine for me (locking the open database that is)
If you get an error like Service 'org.keepassxc.KeePassXC.MainWindow' does not exist. and keepassxc is open, that means the app for some reason is not allowed to use dbus (maybe you're running keepassxc through apparmor or firejail?)

[peterbabic]

qdbus org.keepassxc.KeePassXC.MainWindow /keepassxc org.keepassxc.MainWindow.lockAllDatabases works for me (the database get's locked on gnome-shell 3.36.5, but this command is not executed when I lock my session (thus, the KeeePassXC is still unlocked)

[ioparaskev]

@peterbabic gnome screensaver emits a signal whenever the screen is locked/unlocked. Try something similar as the script posted in https://unix.stackexchange.com/questions/28181/how-to-run-a-script-on-screen-lock-unlock to listen for the gnome screensaver signal and when detected, trigger a signal to lock keepassxc