Occassional unlock without password entered
savchenko opened this issue · comments
This might be related to one of the existing issues. From #987360:
Sometimes when resuming from sleep, Swaylock will respond to the first keypress
of the password and display a spinner, but then freeze for about half a minute
and then just disappear and thereby allow access to Sway without the password
being entered.
Debian bug-report contains core-dumps.
Is there something in particular that can help with investigation of this bug?
Is there something in particular that can help with investigation of this bug?
The stack traces would be a start. Core dumps are not portable.
Based on the provided coredumps it is:
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x000055cc2e8068cd in loop_poll (loop=0x55cc30164780) at ../loop.c:111
#2 0x000055cc2e804eb5 in main (argc=2, argv=0x7ffebdfc1e78) at ../main.c:1235
(gdb) frame 1
#1 0x000055cc2e8068cd in loop_poll (loop=0x55cc30164780) at ../loop.c:111
111 in ../loop.c
(gdb) print *timer
$8 = {callback = 0x0, data = 0x55cc3015e010, expiry = {tv_sec = 59314,
tv_nsec = 713617408}, link = {prev = 0x0, next = 0x0}}
(gdb)
I'm running Sway on Debian Unstable on two laptops, and the Swaylock crash seems to only happen on the older laptop.
Due to this bug swaylock is now removed from the upcoming Debian release: https://tracker.debian.org/news/1244697/swaylock-removed-from-testing/
Due to this bug
swaylockis now removed from the upcoming Debian release
That is a pity. Sway is the best (and only) proper, lightweight Wayland compositor. Turns out jwz was right back in '04.
If you are not running XScreenSaver on Linux, then it is safe to assume that your screen does not lock.
I think it might be worth checking his essay on XScreensaver, and maybe having a swaylock-daemon that would relaunch swaylock on obscure crashes like this one. Defensive programming.
Minimal library usage by the xscreensaver daemon.
The xscreensaver daemon is a critical piece of security software. The reason for this is that, as a screen locker, any bug in the program that causes it to crash will cause the screen to unlock. As soon as xscreensaver is no longer running, the screen is no longer locked. Therefore, great care must be taken to ensure that the daemon never crash. And that it especially never crash as a result of (hostile) input from the keyboard or mouse.
Let's suppose that down in the bowels of some particular version of some particular toolkit library, there lurks a bug. Let's suppose that the nature of this bug is something relatively obscure: say that it's something like, if you hold down 5 keys on the keyboard for 10 seconds then drag the middle mouse button, the text entry widget gets a SEGV. (In fact, I'm not making this up: I saw this very bug once, years ago.)
Now, that's the sort of bug that is not likely to be noticed or fixed, because it's the sort of thing that people "never" do. If that bug was reported against, say, a web browser, nobody would much care: User: "I can crash my web browser by doing this crazy thing!" Developer: "Uh, don't do that then." And that's not a totally unreasonable response.
However, in the context of security software, it matters, because then it's not merely a cute trick that crashes the program: now it's a backdoor password that unlocks the screen.
Bugs like that will exist in GUI libraries; it's inevitable. The libraries are big, and do many different things. So one way to protect against that problem is to keep the number of libraries used by the xscreensaver daemon to an absolute minimum.
I would chip in with code if I knew more C.
How about launching swaylock somewhat like this by default to automatically reenable on error?
trap swaylock SIGHUB SIGINT SIGQUIT SIGKILL SIGTERM SIGABRT SIGSEGV; swaylock
It could be done from a small shell wrapper script.
Edit: ... which needs to call itself recursively. See below.
That is a pity. Sway is the best (and only) proper, lightweight Wayland compositor. Turns out jwz was right back in '04.
Sway is still present and I don't see anything threatening its inclusion. In fact, I suspect that with a bit of luck we might see 1.6.X back-ported in Bullseye.
Only the swaylock was removed.
Can you try running with ASan? The stack trace doesn't make it immediately obvious what's going on.
Can you try running with ASan?
@emersion So I need to enable the AddressSanitizer compiler option? How would I do that in the swaylock build config?
Sway is still present
Yea, but swaylock is the only screenlock so it's fairly essential. XScreensaver kinda almost works — it blocks the screen but keypresses can pass through.
Here's my initial proposed fix, swaylockd, that I'll at least be using myself, because I do need that lockscreen to lock. Just run swaylockd instead of swaylock in your config to try.
An attacker could still get a quick glance at the screen below while swaylock is crash but I believe it's an improvement from a full desktop unlock.
meson build/ -Db_sanitize=address,undefined
Another thing to check would be whether latest master still fails. The way commit a99afe6 changes the code in question might (or might not) fix the problem.
I wrote a dumb launcher swaylockd for swaylock that ensures it's running no matter what – immediately restarts swaylock if terminated by a signal (e.g. crashed) and also blocks all signals (except SIGKILL and SIGSTOP, ofc). Moreover, it ensures that only one instance per user is running.
EDIT: I use swaylock on Alpine Linux and haven’t encountered any crash of swaylock yet.
Can you try running with ASan?
For the reference: #196 (comment) and two subsequent comments.
For the reference: #196 (comment) and two subsequent comments.
This doesn't give any useful info on the crash, sadly.
This doesn't give any useful info on the crash, sadly.
Is there a debug interface of some kind or shall I gdb swaylock XXXX as root when it is stuck occupying 100% of the CPU core?
What can help you to resolve this issue?
I consider this to be a problem with the protocol swaylock is using. That protocol should ensure that if swaylock crashes, the screen stays locked, and swaylock is automatically restarted.
There is plenty of discussion on the matter of a lockscreen protocol. Please see swaywm/wlroots#2706, swaywm/wlroots#3165 and swaywm/sway#6483.
There is plenty of discussion on the matter of a lockscreen protocol. Please see swaywm/wlroots#2706, swaywm/wlroots#3165 and swaywm/sway#6483.
ext-session-lock-v1: new protocol implementation fixes the first link (merged in wlroots 0.16).
Second link moved to https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3165 and was closed and I think due to the commit above?
Implement ext-session-lock-v1 implemented that protocol in sway.
I don't know if that means that this issue is fixed now, but a status update seems useful in any case.
Yeah, this kind of issue (swaylock crash causing unlock) is mitigated by the new protocol.