swaylock
swaylock copied to clipboard
Swaylock doesn't set LockedHint
I'm submitting a…
[ ] Bug [x] Feature Request [ ] Other (Please describe in detail)
Swaylock should set the LockedHint property so that the applications can act accordingly.
An example of this kind of response: https://github.com/keepassxreboot/keepassxc/issues/3339 - a password manager could lock it's database on screenlock, but that currently doesn't seem possible with swaylock, since there's no lock event.
It was implemented in systemd in this PR: https://github.com/systemd/systemd/pull/3238 Support was added to ConsoleKit in this commit: https://github.com/ConsoleKit2/ConsoleKit2/commit/d28abf140190c31623aa3af29be609243c4e7a91
See also: https://github.com/i3/i3lock/issues/239
I don't think I'd want to add D-Bus stuff to swaylock itself. A wrapper script could take care of the D-Bus stuff, I think.
I personally use this small tool to synchronize stuff to the locked state: https://git.sr.ht/~kennylevinsen/follow-ready
Someone would have to write a tool to set the lock hints though.
A related Sway issue: https://github.com/swaywm/sway/issues/7008.
I don't think I'd want to add D-Bus stuff to swaylock itself. A wrapper script could take care of the D-Bus stuff, I think.
Hm, what about if it was kept fairly contained (i.e. in a logind.c or dbus.c file)? Fwiw, we already have some optional logind deps in swayidle (but we don't use dbus directly), and while I do agree having dbus stuff in swaylock isn't the best thing, a wrapper is a bit messy as it'd be nice to also support the full API of logind for locking and unlocking sessions, and I'd argue that for systemd systems at least running swaylock on itself is a little "insecure" - whenever I put my laptop to sleep I see a flicker of my desktop before the locker shows up again, because logind doesn't wait for swaylock. A wrapper script could probably fix that, but I do think considering the implications it would be useful to have this in swaylock itself.
Actually scratch that - in the next release of systemd, logind should have a varlink API, would that suffice?
and I'd argue that for systemd systems at least running swaylock on itself is a little "insecure"
Use of systemd-logind locked state has no impact on security on its own. The flicker you're referring to is resumed kernel display driver state because the laptop was suspended before sway submitted a rendered a frame containing a locked screen to the kernel. Only when resumed does sway finally catch up and submit the new frame.
If you believe you need this, start with a wrapper, then one can later discuss whether it needs to be integrated, but it's unrelated to the issue you're describing which would require other swaylock or sway changes.
Actually scratch that - in the next release of systemd, logind should have a varlink API, would that suffice?
That API is quite incomplete, just enough to run pam_systemd.so to create a user session without dbus basically.
See https://github.com/swaywm/swaylock/pull/425 for a take on solving the flicker (when suspending after swaylock daemonized or signaled readiness).