I have an older Intel laptop that has a 1600x900 display, and I find that if I put the machine to sleep, connect an external monitor with a higher resolution, and then turn it back on, the login screen doesn’t adjust to the new resolution and it reveals what I had open (see photo).
However, I’m not that familiar with Linux Mint (even though I’ve daily driven Linux for nearly 10 years, I very casually use LMDE) and I’m not sure if this is a Cinnamon problem or if the lock screen is under a different program.
Looking at Linux Mint’s webpage on reporting a bug (https://projects.linuxmint.com/reporting-an-issue.html) they seem to mostly use Cinnamon as an example, but I don’t want to report this issue as a Cinnamon issue if it’s the wrong project.
In case this is platform specific, my device’s details are below:
- Host: Dell Latitude E6420
- CPU: Intel Core i7-2630QM (Sandy Bridge)
- GPU: Intel 2nd Generation Core Processor Family
- Kernel: 6.1.0-21-amd64
- DE: Cinnamon 6.0.4
- WM: Mutter (Muffin)
- Display Server: X11
I’ve never filed a bug report in my life before, usually I just put up with the issue until it’s eventually fixed, but I feel this is a moderate security issue that should be flagged.
You must log in or register to comment.
Go ahead and report it to the Mint team. Even if it is an issue upstream, they will verify the issue and then report it as well. Never hesitate to report a bug you find, especially if it’s a security or privacy issue.
Even if the bug is a duplicate, it helps to know other people are having the same issue. At worst they will mark your report as a duplicate, which will let you know they are aware of the issue.
Keep in mind that if it is a serious security issue many projects have a way of reporting them separately from other bug reports so the issues can be patched before being published.
This is a known Xorg issue. Distros like TAILS have patches (can’t find a source right now, but it was probably 6+ years ago). The solution is Wayland, since despite TAILS fixing it, no one else seems to have bothered.
(I have the same problem on Fedora 40 XFCE)
I believe it’s also highly recommended to use Xscreensaver specifically as the author is well aware of the risks and limitations and does as much as possible to guard against all known ways to bypass it.
KDE did bother, this does neither happen with KScreenlocker, nor do non-screenlocker windows show in another way, because the screen locker is integrated with the compositor.
If the compositor crashes or gets disabled somehow ofc though, that integration doesn’t help either and you have to rely on a mountain of bad hacks as well as the hope that the screen locker doesn’t also crash for nothing to happen in that case, but it’s as close to secure screen locking as you get on Xorg… in the end the solution for secure screen locking is still Wayland.
When my KDE screenlocker crashes on Wayland, all my monitors tell me to switch to a TTY and run a manual unlock. Which is reassuring!
I recently realised that TAILS uses Wayland. For whole time I’ve been thinking that it uses X11 like Debian by default, but to my surprise, it doesn’t.
That definitely looks like a Cinnamon bug, specifically its screensaver component. Worst case they’ll direct you to where to report the bug, or they’ll move the ticket themselves.
Also, obligatory this is one of the many ways X11 is insecure and unsuited to proper screen locking. Lock screens on X11 are just fullscreen windows you pray the window manager won’t ever allow to unfocus, close, resize or move or not cover the rest of the desktop.
This is a Xorg issue and there isn’t much of a fix. Anytime the lockscreen malfunctions you can get access to the desktop.
Wayland doesn’t have this issue by design
This shit right here is why you absolutely must use xscreensaver.
Not some repackaging of the hacks.
Not some implementation with your wms decorations.
Xscreensaver.
Or Wayland, where this isn’t an issue.
I like my security bugs well publicized with documented workarounds as opposed to undiscovered and undisclosed, thank you.
Apropos of nothing, Xscrensaver is my bellwether for moving to Wayland. When it’s officially ported I’ll switch.
I doubt there will ever be screensaver support with Wayland. Wayland isn’t a program so there is not a display server to connect to. The desktop draws directly to the screen.
Swaylock?
I mean, it absolutely could if stuff like ext_session_lock weren’t incredibly insecure.
There’s a thread on the maintainer of xscreensavers website that talks extensively about this and it got me trying to get just some stubs hooked into several wayland environments, seeing how the sausage is made and putting Wayland back on the shelf.
I tried Linux briefly in highschool (around the year 2000) before going back to Windows (I love video games). I switched about 2 years ago back to Linux (Debian). Your comment made me remember xscreensaver and I went and installed it again. The matrix screensaver is a huge throwback, I love it and I missed it.
But it was a pain to do this. I’m using KDE/Plasma on Debian, and I had to follow this process to get it done. My lock buttons built into KDE menus still don’t work despite replacing kscreenlocker_greet like the manpage recommends. I’m not sure it’s worth my time to try to figure out, since the page warns an update will revert this. I’m not going to remember how to fix it later. I choose to lock my computer with super+L so this isn’t a huge issue for me.
The process to use xscreensaver with gnome looks equally bad.
WHY is this so tough, though? Debian “just works” for me, so needing to fumble through this manpage feels pretty lame. The process looks similar on other distros, from a quick google. I’m not an IT person or a programmer, and this doesn’t feel very “linux” that it’s this way. Why would these window managers replace something that just works?
I suppose it does look a bit dated?
None of the desktop environments like xscreensaver because it breaks their window decorations and input handling. It does this for security purposes because its job is first and foremost to be as secure as possible then once that’s done go ahead and make pretty pictures.
If it sounds crazy that input and window decorations would be insecure, peruse the maintainers webpage and be horrified.
Wayland needs infinite workarounds to get xscreensaver working because the way you’d do it under the Wayland framework is with a weird method called uhh ext_session_lock (I reference it in another comment but I’m not sure that’s the right one now.) which at least as of about a year ago let screen locking programs handle passwords directly!
I think it’s an artifact of open source software being maintained by people who are on the payroll of companies that rely on the software.
Thanks for taking the time to reply, that makes a lot of sense.
I haven’t switched to Wayland yet. It makes sense why xscreensaver wouldn’t work well with an entirely different window server. I was just surprised it was so difficult (for me at least) to use with modern window managers despite being relevant and mature, haha.
I’ve seen similar on my desktop on proton when on wake it crashes the display manager and shows my locked desktop unlocked with all the running applications before it finishes crashing closing all my applications and then going back to login screen.
Yes, go ahead and file the bug. And as others mentioned already, the custom screensaver modifications of XScreensaver like for LM may have bugs. The author of XScreensaver has been complaining about this several times.
The bug you found looks similar to this one :
Unlocking a machine locked with Xfce’s screensaver xfce4-screensaver has long been a simple matter of turning two monitors on at the exact same time. That makes Xfce4-screensaver versions prior to 0.1.9 segfault and crash - leaving the machine unlocked. This very unfortunate Xfce bug #16102 has been open since October 29th 2019 and we have pointed fingers at it several times before. Xfce developer Sean Davis has finally closed this gaping security hole. He explained that the embarrassingly long delay before this security vulnerability was addressed was due to “real life conflicts” in a brief comment on March 22nd. He did not elaborate and we did not ask for further details since it is likely none of our business.
