-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keyboard input bypasses swaylock when monitor is off, can interact with focused window underneath #204
Comments
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. |
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. |
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. |
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 |
That protocol is superseded by https://wayland.app/protocols/ext-session-lock-v1, implemented in swaylock in #219. |
Is the solution in #219 ready for testing via Sway Yet? |
Nope, Sway doesn't support ext-session-lock atm. |
Is support for |
Patches welcome. |
I experience the same issue. Does |
Yes. This issue cannot be reproduced with the |
ext-session-lock is now released in sway 1.8! Maybe this issue can be closed now? |
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 |
recording-2023-05-12_13.54.40.mp4you 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 |
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?
|
@WhyNotHugo yeah latest master of swaylock, and I use latest master of Hyprland |
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
|
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.
|
what bothers me is this kernel parameter that causes it. I don't understand the link |
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. |
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! |
How to reproduce:
Probably related to #188. Seems like a pretty significant security issue. Let me know if you need more details about my configuration.
The text was updated successfully, but these errors were encountered: