Keyboard input bypasses swaylock when monitor is off, can interact with focused window underneath

[and-reas-se]

How to reproduce:

1. Use sway as window manager (possibly works with others, but only one I tested with sway).
2. Leave a terminal window focused on screen (I used alacritty if that makes a difference).
3. Lock computer with swaylock using keyboard shortcut that starts it.
4. Turn off monitor (connected trought displayport in my case).
5. With monitor off, type some terminal command on your keyboard and press enter.
6. Turn monitor back on, and enter your password to unlock computer.
7. You will now see that the command you typed when the monitor was off and your computer was locked was executed in the terminal.

Probably related to #188. Seems like a pretty significant security issue. Let me know if you need more details about my configuration.

[maxrp]

I've observed this as well, although I also use Alacritty I can replicated this behavior with Sublime Text, Firefox or Alacritty as the underlying window.

I concur on steps to replicate -- except that it seems to work with any highlighted window.

[danieldg]

Note: I've not tried to reproduce, but I think this might be caused by swaylock not having an active window when all monitors are disconnected ("off" can sometimes mean "disconnected"). In that case, there's no window for an input grab to be associated with. If this is the cause, changing swaylock to always make a window (even if no outputs are present) might be needed. Changing the compositor to not give back input focus just because a locker closes (swaywm/wlroots#2706) will fix this and many other swaylock security issues.

[baldimir]

I am observing this too. Sometimes I see the part of my password that I type while my external screen is off in a text input if I have one selected before I lock my computer. This is a serious security concern to me.

[eloeffler-fhnw]

There has been a merge request on wlroots for several months months which is currently not in a working state because it needs to be adapted to changes in wlroots.

https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3165

[kennylevinsen]

That protocol is superseded by https://wayland.app/protocols/ext-session-lock-v1, implemented in swaylock in #219.

[markstos]

Is the solution in #219 ready for testing via Sway Yet?

[emersion]

Nope, Sway doesn't support ext-session-lock atm.

[nyancow]

Nope, Sway doesn't support ext-session-lock atm.

Is support for ext-session-lock planned? If so, where is it tracked?

[emersion]

Patches welcome.

[PanAeon]

I experience the same issue. Does ext-session-lock help?

[WhyNotHugo]

I experience the same issue. Does ext-session-lock help?

Yes. This issue cannot be reproduced with the ext-session-lock protocol. However, you'll need to build sway from master, since this feature hasn't made it into a stable release yet.

[Smona]

ext-session-lock is now released in sway 1.8! Maybe this issue can be closed now?

[primalmotion]

This happened to me again this morning with latest master. Impossible to type on swaylock, switched tty to SIGUSR1, my terminal was filled with the gibberish I typed. I can easily reproduce

[primalmotion]

recording-2023-05-12_13.54.40.mp4

you don't see it on the video obviously, but the laptop suspends. when swaylock shows, it's after I wake up the system. You don't see it either, but while swaylock is there, I type. finally I hit a shortcut I added to send sigusr1 to swaylock. You can see that what I typed has been typed in my terminal

Edit I'm on Hyprland, according to @vaxerski, it may be hyprland faults. But I also want to point out that this is related to my other issue #297 : this does not seem to happen when I don't set no_console_suspend

[WhyNotHugo]

On Fri, 12 May 2023, at 22:54, primalmotion wrote: This happened to me again this morning with latest master. Impossible to type on swaylock, switched tty to SIGUSR1, my terminal was filled with the gibberish I typed. I can easily reproduce

Latest master of swaylock? Which sway version?

[primalmotion]

@WhyNotHugo yeah latest master of swaylock, and I use latest master of Hyprland

[WhyNotHugo]

On Fri, 12 May 2023, at 23:21, primalmotion wrote: @WhyNotHugo <https://github.com/WhyNotHugo> yeah latest master of swaylock, and I use latest master of Hyprland

Sounds like a bug in Hyprland, see discussion in hyprwm/Hyprland#799

[WhyNotHugo]

On Fri, 12 May 2023, at 23:27, Hugo Osvaldo Barrera wrote: On Fri, 12 May 2023, at 23:21, primalmotion wrote: > > > @WhyNotHugo <https://github.com/WhyNotHugo> yeah latest master of swaylock, and I use latest master of Hyprland > Sounds like a bug in Hyprland, see discussion in hyprwm/Hyprland#799

Scrub that, I'm thinking of another scenario.

[primalmotion]

what bothers me is this kernel parameter that causes it. I don't understand the link

[kennylevinsen]

Anything causing input to end up in the wrong window when using ext_session_lock_v1 would be a compositor focus bug. Focus calculations quickly end up with a lot of edge cases, so it's tricky to get right. Make sure that protocol is in use though - layer shell and input inhibitor is a another beast entirely.

no_console_suspend might just affect some timings or suspend order that affect input events and focus calculation triggers.

[primalmotion]

Ok that makes sense. It seems Hyprland is arleady having several issues with multimonitors combined with suspend. So yeah no_console_suspend is probably making the existing bug worse. which is good in a sense :) thanks!