Skip to content
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

i3lock can be killed on wayland #243

Closed
wanneut opened this issue Aug 7, 2019 · 5 comments · Fixed by #290
Closed

i3lock can be killed on wayland #243

wanneut opened this issue Aug 7, 2019 · 5 comments · Fixed by #290

Comments

@wanneut
Copy link

wanneut commented Aug 7, 2019

I'm submitting a…

[ ] Bug
[ ] Feature Request
[X] Other: Vulnerability

Current Behavior

If i3lock is running on xwayland shortcuts still work. This especially include positioning some window in front of i3lock. Just search a terminal and call killall i3lock – or whatever you want.

Expected Behavior

i3lock should lock your screen and should not be able to be disabled.

Reproduction Instructions

1. add bindsym $mod+m exec killall i3lock to your sway config
2. start i3lock
3. press $mod+m

Proposed workaround

show a warning message instead of locking the screen, if you detect running on a wayland compositor.

Environment

Output of i3lock --version:

i3lock version: 2.11.1
@Airblader
Copy link
Member

i3lock is a screen locker for X11, we do not intend or test with Wayland and therefore I would strongly discourage anyone from using it.

That said, given the "severity" if it's simple enough to detect Wayland usage, I would accept a PR that exits immediately and prints something to stderr.

@wanneut
Copy link
Author

wanneut commented Aug 12, 2019

Problem is, that I don't really know how to do it in a nice way:
At first I thought about checking the Vendor String (with xcb_setup_vendor). But it seems that it is "The X.Org Foundation" for Xwayland. Wtf?!
I have definitely no X.Org-Server installed.

Then I tried to connect to Wayland. But this just evaluates $WAYLAND_DISPLAY and if it is not set it checks if the socket "/run/user/$UID/wayland-0" is existent. So if you reset $WAYLAND_DISPLAY but not $DISPLAY. This won't work either. My be a rare case. But still more a heuristic than a check.

@ddevault
Copy link

I would suggest that is not a bug and that i3lock cannot be reasonably expected to behave well in a non-X environment. swaylock is 1:1 compatible with i3lock and is for Wayland, you should use that instead. If you insist on testing for it in i3lock, maybe check for outputs name XWAYLAND-*, but I suggest just forgetting about it. I don't think this complaint is reasonable.

@Airblader
Copy link
Member

@ddevault Thanks for your input. I totally agree that we don't intend i3lock to work on Wayland I would rather have users switch to swaylock. I do think we should make sure to immediately exit in such a case though, rather than – which is what appears to happen – showing the lock image while in fact nothing is locked, as that misleads the user into thinking the system is locked.

@ddevault
Copy link

I mean, I don't know of anything which comes with i3lock pre-installed except for i3, which is an X11 window manager. Users who explicitly chose to install i3lock in these circumstances should know better. It's your call but I'd CLOSED WONTFIX this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants