Open aaime opened 7 years ago
I'm too on Linux Mint 18.1 but unable to reproduce the bug. Maybe some problem in your lock screen configuration.
Some other users have this issue as well: https://www.reddit.com/r/linuxmint/comments/5kib0l/linux_mint_181_screensaver_lockscreen_issues/
I am facing the same issue
Same with me.
Running Arch Linux with this version :
[arteal@quagmire ~ ]$ cinnamon-screensaver --version
cinnamon-screensaver 3.2.13
If you stop then restart cinnamon-screensaver from a terminal, do you get any errors when this behavior occurs?
If it's running, do:
cinnamon-screensaver-command -e
or use killall cinnamon-screensaver
as root, then:
cinnamon-screensaver --debug
This will spit out some extra authentication and locking information while it runs. Note, if you're still running <=3.2.12, debug mode would spit out all auth communication, including plain password strings. Version 3.2.13 removed that. Please be sure to redact any occurrence of such, or upgrade to 3.2.13 before testing this, and pasting the output.
Thanks
The installation of python-setproctitle
(as described in #193) solved the issue for me.
I originally had this issue as well, but it seemed to have been resolved in one of the recent package updates.
Just now - and perhaps once or twice before - I have had a similar problem. To wit: my laptop had suspended itself; I woke it up; entered the BIOS password and . . no lock screen, no request for a user password. Mostly, though, I am asked for the user password - my point is that sometimes this does not happen, which strikes me as security risk.
Cinnamon 3.2.7.
Same here. Killing the screensaver process and restarting it appears to fix it when it starts acting up.
Same problem for me, the screensaver "gets off the bus".... randomly. So much for using a LUKS encrypted laptop if the screensaver just dies for no good reason.
$ cinnamon-screensaver --version cinnamon-screensaver 3.2.13
Jul 3 19:09:46 andrewm-Satellite-P50-A cinnamon-session[26218]: WARNING: t+37039.48962s: Detected that screensaver has left the bus
This problem started for me after upgrading Linux Mint from 18 to 18.1.
I am experiencing this same issue -- Mint 18.2 and 18.3 with cinnamon-screensaver 3.4.1. When I killed cinnamon-screensaver and restarted in debug mode, it correctly prompted me for a password. Before that, issue persisted through system halts and the 18.2 - 18.3 upgrade/restart
Upgraded to 18.2 now (Linux Mint). Same problem. I had previously installed the python-setproctitle package even though the python3 version was installed. It didn't help. Now the older version is required for blueberry.... go figure.
This is ludicrous, FDE is pointless when someone can walk up to a machine and get access just because the screensaver aborted; that person doesn't even need a password at all!
$ cinnamon-screensaver --version cinnamon-screensaver 3.4.1
$ cinnamon --version Cinnamon 3.4.3
It's frustrating to try to fix a bug you can't reproduce as well. The FDE note is new, however..
Does everyone having this issue use encryption of some sort?
Does this happen in a new user's session of you create one?
You all have to understand, if you don't give me sufficient information to reproduce something, the chances of it getting fixed are pretty low. The problem is sometimes you guys don't know what info is relevant, and sometimes I just don't ask the right questions ;)
Does everyone having this issue use encryption of some sort?
I do not use encryption (I did once try encrypting my home partition and it broke something - I can't remember what - so I had to remove it, sadly). Or I don't unless one counts VeraCrypt.
Does this happen in a new user's session of you create one?
I am afraid I don't know and I can't find out, because I saw the problem only once, some months ago.
Relevant system information (er, for my system now; I had earlier versions of Cinnamon and the screensaver - respectively - when I had the problem):
$ cinnamon-screensaver --version
cinnamon-screensaver 3.4.1
$ cinnamon --version
Cinnamon 3.4.3
@mtwebster I'm using the mint provided FDE as well. However, I'm having issues with it not always successfully loading the decryption prompt and thus the system not booting so I'm looking into alternatives. If I reset the system to otherwise identical install but no FDE I'll let you know results. I also haven't halted the system since I used the restart option which fixed it for this session, I'll let you know results from that.
For those coming across this the first time, if the restart fixes your issue you can restart again without debug mode and disown the process to return to normal operation.
I'm watching the thread since I started having the issue, so let me know if you have further questions or want me to test anything.
I wouldn't think that FDE would be relevant. The common thread is a migration from 18 to 18.1 and now 18.2 for Linux Mint at least. I can leave my laptop locked, go away and come back later to find it isn't locked and the screensaver has left the bus.
In my case (18.1) it's not dying anymore, but every time I unlock I can see the screen contents for a good while (1-2 seconds) before the lock screen appears and I can enter the password. Not good, the screen might contain private information that anyone can have a look at (repeatedly too, if they have some patience).
@aaime I don't think that's related to cinnamon-screensaver specifically, I've had that happen to me when coming back from blank lock screen on Ubuntu. It doesn't happen every time, but enough I've noticed and started trying to track it down. So I think it's an upstream problem with locking
There was a locking issue fixed in cinnamon-session for 3.4 (mint 18.2) - https://github.com/linuxmint/cinnamon-session/commit/c2d18069e62c331ba65551871d2d15cd27ebbc85.
It wouldn't affect everyone, but if had normal screensaver locking off, but still wanted to lock when suspending or hibernating, this could end up causing a visible desktop briefly when coming back. The fix ensures the locking occurs fully prior to suspend/hibernate.
I also never considered encryption to relevant, but clearly if some people are having issues, we're missing something, so I'm willing to entertain anything that may be 'different' from the norm with users. I need to be able to reproduce these issues.
@mtwebster I just made a quick test now that I've upgraded to 18.2, indeed I could not see the desktop anymore. Just one test though, I'll report back if I can see it again.
I don't know if the debug output would help, but I'm sure it would make a good start; you can find it here: https://affinityvision.com.au/cinnamon-screensaver--debug.txt
I fiddled around closing my laptop lid, turning on and off the externally attached screen, locking with keyboard shortcut, allowing the lock to happen by itself due to timeout. All the fiddling didn't break anything, until it finally segfaulted.
If you want me to do anything else, please let me know; right now I am heading off to bed though and I've got plenty on tomorrow, so I don't know when I'll be available next.
Hmm if I could get a trace where that happens it may shed some light. It can be a bit tricky to get one, since it's the screensaver, and when it's frozen by a debugger, it can make things difficult to interact with a normal desktop.
If anyone is interested, these steps should allow you to get a trace when the screensaver crashes in a fairly painless manner. I would suggest a reboot after going through running the script - you get the occasional zombie processes.
And before someone says it, yes we should have an easier way to do this ;) - we're working on it.
# Download our cin-debug script and make it executable.
# You can just paste this url into a browser and get it that way if you want.
wget https://raw.githubusercontent.com/linuxmint/Cinnamon/master/utils/cin-debug
chmod +x ./cin-debug
# Install a few things...
sudo apt-get install gdb screen cinnamon-dbg
# gdb is the debugger.
# screen lets you have 'virtual' terminals that can be doing something independent of
any reliance on the current graphical environment.
# cinnamon-dbg brings in debug symbols for pretty much all the relevant libraries
we use throughout cinnamon
# Open two terminals
# In the first, run:
cinnamon-screensaver-command -e # kill any existing screensaver
cinnamon-screensaver --debug # start a new one
# In the second terminal, navigate to the folder where cin-debug is...
# start screen, you might get an intro screen, just continue:
screen
# start our script, which attaches to the running screensaver process
# This requires a password, gdb needs root to attach to running processes
./cin-debug cinnamon-screensaver
# The debugger will start up, ending with <continuing..
Ctrl-A, Ctrl-D # detaches back to your original 'terminal'
From here, try to do whatever to get any crash of the screensaver. If/when it does crash, that debugger instance should save a timestamped file in your home folder, something like:
cinnamon-screensaver-2017-07-05-9:52:44.log
Thanks
Just an update, we found what's likely causing the crash during hotplugging and are working on a patch, hopefully in the next day or so to test out.
I'd still love crash reports for those it may be happening to - I'm pretty sure there is more than one issue here (for different posters)
This might just be another puzzle piece but here the cinnamon-screensaver does not show a password-prompt when the user interface scaling is set to Hi-DPI and the external 4k-display is connected. Instead the desktop can be seen, the windows can be switched via the taskbar but I can not focus a window. It seems like the desktop is frozen but when entering the password (blindly without a password prompt) the desktop gets unlocked again.
When switching to "normal" user interface scaling the desktop is locked and the password prompt is shown.
I am running Linux Mint Debian Edition 2 (LMDE2) on a Lenovo X230.
The debug output can be found here.
@jkirk this happens any time the screensaver activates? Or when returning and 'raising' the unlock dialog?
edit: Also, is this a laptop display? What distro are you on? What graphics hardware/driver?
I have a hidpi laptop to test on, I haven't seen anything that broken - i'm curious how your setup may differ from mine.
I think the problem has a lot to do with detecting an external screen; if I completely leave the screen on (don't turn off the power completely), then I'm not seeing the problem. It may also be related to lid-close as well for the internal screen.
Yes, this only happens when my external (4K) screen is connected.
Setting the user interface scaling to "Hi-DPI" when no external screen is connected, just with my notebook screen (with a resolution of 1366x768) the password prompt is shown (in huge letters).
(I updated my comment)
This is indeed related to hotplug events/xrandr changes. The screensaver isn't handling the various events well enough. This is a priority to fix, I'm just waiting on a piece of hardware to do some more complete tests.
I've got a patch ready, just waiting for a bit more internal testing.
https://github.com/mtwebster/cinnamon-screensaver/commit/fce51c4cd4f3b5e6fffa54856e4a4c9b1f7346d0
Any (inofficial) deb-package available which we can test?
Hey, since a few days ago the screen saver locks... too much! When I get back to it, X server seems to lock solid and I cannot move the mouse anymore. 100% repeatable, I have to pay attention not to lock the screen, or I have to drop on the command line and restart mdm. Probably a separate issue but, wondering, anyone else experiencing the same?
Linux Mint changelog????? Understated or what! [ Michael Webster ]
THIS IS NOT JUST A SOFTWARE UPDATE, IT FIXES A MAJOR VULNERABILITY.
I have the same problem: Linux Mint 18.2 Cinnamon 64-bit doesn't prompt for a password after being suspended when I reopen the lid.
I logged cinnamon screensaver logs to the attached file. There are critical errors and failed assertions at the end of the log file.
One more thing: cinnamon-screensaver --debug &>~/cinnamon-screensaver-debug.log
command ended with a Segmentation fault
.
Hope this helps to find the problem and the solution.
Some further info. I find that when I'm working on a dual displays that 1 displays the lock screen and the other is unlocked and I can interact with the "unlocked" with the mouse but all keyboard input is captured by the login screen. I hope that makes sense.
I attached an external monitor while my laptop screen was locked and I got access to the desktop on it. I was able to use the menu/run apps and access the desktop docs while the laptop screen prompted for my password. I reproduced this twice only.
I am also seeing the issue described by jkirk. I use a vertically oriented second monitor, and I can see what looks like the password screen overlay partially obscuring the second monitor at the top of the screen. I'm unable to perform any keyboard input (seems to go to the obscured password prompt). But I can use the trackpad to view, move, minimize, and close windows (and open files). When I unplug the second monitor, the password prompt reverts to the primary screen, and I am able to input my password and unlock the screen. I took a video, which I'd be happy to share in a PM. (Using Cinnamon 3.4.6)
I'm using Cinnamon on Antergos with 2 external monitors over HDMI and experienced the same problem as described by (at least) @johnbburg, @jaliss & @Rusty-1.
I just reproduced it 3 times as follows:
this has a huge security impact, so any comment from the cinnamon-team would be highly appreciated!
cinnamon versions:
Can you run this in debug mode and provide the logging when you reproduce it?
cinnamon-screensaver-command -e
cinnamon-screensaver --debug
sure, here it is: (in between I removed 383 same lines mentioning the "authClient initialize...")
Debug mode active
/usr/share/cinnamon-screensaver/cinnamon-screensaver-main.py:86: Warning: g_base64_encode_step: assertion 'in != NULL' failed
css = provider.to_string()
Cinnamon Screensaver support not found in current theme - adding some...
Trying to connect to logind...
Starting screensaver...
Not running under the session scope, trying XDG_SESSION_ID
found session: c2
Successfully using logind
couldn't grab keyboard
Found 1 Xinerama screens on display :0
Monitor 0 is 0,0 1920 x 1080
Cinnamon Screensaver compiled without Solaris Xinerama support
Scale factor of 1 applied. Monitor 0 is 0,0 1920 x 1080
Stage.update_geometry - new backdrop position: 0, 0 new size: 1920 x 1080
Found 2 Xinerama screens on display :0
Monitor 0 is 0,0 3840 x 2160
Monitor 1 is 3840,0 1920 x 1200
Cinnamon Screensaver compiled without Solaris Xinerama support
Scale factor of 1 applied. Monitor 0 is 0,0 3840 x 2160
Scale factor of 1 applied. Monitor 1 is 3840,0 1920 x 1200
Stage: Received screen monitors-changed signal, updating monitor views
Stage: Received screen changed signal, updating backdrop
Stage.update_geometry - new backdrop position: 0, 0 new size: 5760 x 2160
Found 2 Xinerama screens on display :0
Monitor 0 is 0,0 3840 x 2160
Monitor 1 is 3840,0 1920 x 1200
Cinnamon Screensaver compiled without Solaris Xinerama support
Scale factor of 2 applied. Monitor 0 is 0,0 1920 x 1080
Scale factor of 2 applied. Monitor 1 is 1920,0 960 x 600
Stage: Received screen monitors-changed signal, updating monitor views
Notification received...
Sender: NetworkManager
Summary: Connection Established
Body: You are now connected to “Wired connection 1”.
Found 3 Xinerama screens on display :0
Monitor 0 is 1920,0 1920 x 1200
Monitor 1 is 0,0 1920 x 1200
Monitor 2 is 0,1200 1920 x 1080
Cinnamon Screensaver compiled without Solaris Xinerama support
Scale factor of 2 applied. Monitor 0 is 960,0 960 x 600
Scale factor of 2 applied. Monitor 1 is 0,0 960 x 600
Scale factor of 2 applied. Monitor 2 is 0,600 960 x 540
Stage: Received screen monitors-changed signal, updating monitor views
Stage: Received screen changed signal, updating backdrop
Stage.update_geometry - new backdrop position: 0, 0 new size: 1920 x 1140
Found 3 Xinerama screens on display :0
Monitor 0 is 1920,0 1920 x 1200
Monitor 1 is 0,0 1920 x 1200
Monitor 2 is 0,1200 1920 x 1080
Cinnamon Screensaver compiled without Solaris Xinerama support
Scale factor of 1 applied. Monitor 0 is 1920,0 1920 x 1200
Scale factor of 1 applied. Monitor 1 is 0,0 1920 x 1200
Scale factor of 1 applied. Monitor 2 is 0,1200 1920 x 1080
Stage: Received screen monitors-changed signal, updating monitor views
authClient initialize... initialized already: False
authClient initialize... initialized already: True
authClient initialize... initialized already: True
authClient initialize... initialized already: True
authClient initialize... initialized already: True
authClient initialize... initialized already: True
pam_start ("cinnamon-screensaver", "cschwarzbauer", ...) ==> 0 (Success)
Handling message style 1: 'Password: '
Waiting for respose to message style 1: 'Password: '
Waiting for lock
Waiting for response
Got message style 1: 'Password: '
Output from pam helper: 'CS_PAM_AUTH_SET_PROMPT_Password: _'
authClient idle add auth-prompt
Output from pam helper: 'CS_PAM_AUTH_BUSY_FALSE'
authClient idle add auth-busy
Output from pam helper: ''
authClient initialize... initialized already: True
...
383x same message -> removed
...
authClient initialize... initialized already: True
authClient message to child
authClient initialize... initialized already: True
auth_message_handler processing response string
should interrupt: 0
Got response
Got respose to message style 1: interrupt:0
Msg handler returned 1
Output from pam helper: 'CS_PAM_AUTH_BUSY_TRUE'
authClient idle add auth-busy
Output from pam helper: ''
pam_authenticate (...) ==> 0 (Success)
pam_acct_mgmt (...) ==> 0 (Success)
pam_setcred (...) ==> 0 (Success)
pam_end (...) ==> 0 (Success)
Verify user returned: TRUE
Output from pam helper: 'CS_PAM_AUTH_SUCCESS'
authClient idle add success
Output from pam helper: ''
authClient message to child
authClient helper process completed...
CsScreen dispose
CsScreen finalize
Currently experiencing this with Tara, cinnamon 3.8.8. Lock screen variously not doing anything at all, or showing an unlocked lock screen, and suspend suspending without locking.
i am having same experience as russmack above.
for me first time i am experiencing this problem.
is there a way to completely remove cinnamon-screensaver from linux mint 19 and still get screen locking and suspend (all i need) ?
@christian-schwarzbauer Do you have hidpi scaling set to "Auto"? (Cinnamon-settings -> general)
It appears that at different times the scaling changes, causing incorrect calculation of the screen size. I suspect this may be caused by having monitors of varying resolutions, with sleep/wake causing detection to be calculated on different monitors at different times.
Could you set that option to "Normal" or "Double" rather than "Auto"
@GrangeBeach You don't need a screensaver for suspend, but you do for locking. Could you try the steps here?
Another test would be to create a new user and see if it functions properly under that user. These would be a good start for troubleshooting.
Thanks
Forum post on the Mint forums, for reference: https://forums.linuxmint.com/viewtopic.php?f=208&t=274155&p=1502954#p1502954
I've managed to make one of the issues (not properly locking the screen when suspending the computer) 100% reproducible on Linux Mint 19 Cinnamon with the following package versions:
cinnamon 3.8.8+tara
cinnamon-screensaver 3.8.2+tara
This might not address all the underlying causes, but it's a start! Perhaps the developers can use this to further investigate the code that needs to be rewritten. I will post this finding on the GitHub bug reports.
Here is how I can trigger this issue, and here is the text from --debug mode:
Calling XResetScreenSaver
manager: user activity, waking
manager: not locked, queueing idle deactivation
CsScreen dispose
CsScreen finalize
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
Nuking focus
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab mouse
couldn't grab mouse
couldn't grab mouse
couldn't grab mouse
Calling XResetScreenSaver
Here is how I discovered a way to 100% reproduce this security issue:
1) Make sure you have it set to suspend on closing the laptop lid and to lock the screen upon suspend and when the screensaver starts. Settings > Screensaver > Settings and also Settings > Power Management > Power
2) Create a shortcut key / key combination for suspending the computer to RAM. If you have it set to suspend upon closing the lid, it will behave the same way if you follow the next steps.
3) Right-click somewhere, such as on the taskbar or a file or the desktop itself, in order to bring up a context menu. Do not do anything else with the mouse. Leave the cursor where it is.
4) Now close the laptop's lid. Wait a while, and you will hear the system go into suspend mode.
5) Now open the laptop's lid and you will hear the system wake up.
6) You have access to your entire unlocked session, completely bypassing any password dialogue or lock screen!
This can also be done via the shortcut keys, but it requires a more unlikely (though not improbable) timing of events. I had success exploiting the issue: if your press the shortcut key to suspend, and immediately bring up any context menu (or any such menu to steal the cursor's focus), you can reproduce the issue. However, the timing needs to be precise, so it's less likely to happen, yet it can still happen by mistake.
This still does not explain why there is a general degradation of Cinnamon over time, and why the screen locker gets slower and slower over time. They might be separate issues, or perhaps inter-related with this one. I hope this post helps the developers narrow down their search for the code responsible for this vulnerability.
@flansuse This is a known issue. There is at least one other open here about it. I don't remember the specifics but this will happen with any application menu open. It has to do with how focus works and I'm not sure we can even change it on our side.
https://github.com/linuxmint/cinnamon-screensaver/issues/258 https://github.com/linuxmint/cinnamon-screensaver/issues/93
@JosephMcc Is this unique to Cinnamon, or applies to any desktop?
I guess it doesn't address the other issue of degradation, where the system will eventually refuse to suspend, or will still grant access to an unlocked session, without exploiting the cursor / menu bug.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
All I have to do for the screen saver NOT to lock, is to open the cinamin menu and leave the laptop alone, when I come back, the screen is blank, but it doesn't lock and no password is required to contniue.
ii cinnamon 3.6.7+sylvia
amd64 Modern Linux desktop
un cinnamon-bluetooth
The Mint lock screen reliably shows my desktop and even lets me interact with elements of the desktop when I switch between displays after locking. Is it just using some sort of overlay to block interactions and that's not scaling when the display settings change? Seems really insecure and unusable as a security tool.
@mtwebster The problem disappears when setting hidpi scaling from "Auto" to "Normal" or "Double". My setup is: A laptop with QHD display and an external monitor (via DisplayPort) with HD resolution. Problem: When I connect the external monitor the lock screen changes its size to 1920x1080 on the QHD display and to 960x540 on the HD monitor. This ends up with the lock screen covering only 1/4 of each screen.
Having this on Linux Mint 19 MATE just today; had been working fine before that. I know this is a cinnamon thread but I thought I would post here in case the culprit lies deeper. My only updates before the latest restart were:
On a Linux Mint 18.1, I lock the screen either using "CTRL-ALT-L" or picking "lock screen" from the cinnamon menu. The lock screen with the clock appears, but at the first mouse movement or click it will unlock and return to the desktop immediately, without asking for a password.