Add swaylockd – a dumb launcher to spawn swaylock and ensure it’s running no matter what #71
Conversation
|
See also swaywm#209 |
|
Hmm. This approach does have some merit, it will fix (big) security issues for the situation where Swaylock crashes due to some one-time issue. However, I've thought about these issues a bit as well, and the solution I think I prefer is to have a stupid minimal lock screen which literally does nothing else than putting fullscreen windows on the screen, so that if swaylock crashes, the screen remains locked. I haven't gotten around to implementing something like that though (and I've taken a break from wayland/sway programming in general lately). However, swaylockd isn't a bad idea even if I get around to that, since even such a minimum viable screen locker program could crash, for example if a bug in Sway causes the Wayland connection to die. I suppose this is a case where a belts-and-suspenders approach is appropriate. I wonder though if swaylockd should relaunch swaylock without any options when it crashes, as a kind of safe mode, in case any of the options caused the crash. Also, since most users will probably run swaylock-effects in a way where the lock screen is a screenshot of whatever's behind it (after applying some effects), I'm a bit worried about relaunching with effects active but with a new screenshot. A normal use case is probably to make sure nothing too sensitive is on screen, then lock the screen and go away. If you do that, and something very sensitive appears behind the lock screen, and then swaylock-effects crashes and is re-launched, (a blurred version of) that very sensitive content will be the lock screen. |
See the provided man page swaylockd(1) and this comment in swaylock#18.
I also released it as a standalone project https://github.com/jirutka/swaylockd, but I think the swaylock stability issues (actually, it’s more a bad design) are so severe that it’ll be better provided directly with sway(-effects). However, it’s still just a low-effort workaround…