mate-desktop / mate-screensaver

MATE screen saver and locker
https://mate-desktop.org
GNU General Public License v2.0
48 stars 40 forks source link

mate-screensaver screen lock can be bypassed by power cycling monitor [$110] #155

Closed fizzfaldt closed 5 years ago

fizzfaldt commented 6 years ago

Expected behaviour

Lock Screen Turn off monitor (either by power management putting it to sleep, or by pressing power button) Turn monitor on Start typing Expect to see lock screen on monitor

Actual behaviour

Lock Screen Turn off monitor Turn monitor on Start typing Expect to see lock screen on monitor

Steps to reproduce the behaviour

adddate() {
   while IFS= read -r line; do
      echo "$(date) $line"
   done
}
killall mate-screensaver
mate-screensaver --no-daemon --debug 2>&1 \
  | adddate  > screen.log

Wait 60 seconds Lock screen (I used Window manager shortcut) Wait 60 seconds Power off monitor (soft off) Wait 60 seconds Power on monitor Wait 9 seconds (that's how long it takes monitor to boot) Can see and use screen/type/etc; it is (effectively) unlocked.

Notes/logs: mate-screensaver-command -q reports:

Same as above, annotated with logs: (attached for ease of reading) mate-screensaver --no-daemon --debug mate-screensaver-1.txt

Wait 60 seconds Lock screen (I used Window manager shortcut) mate-screensaver-2.txt

Wait 60 seconds Power off monitor (soft off) mate-screensaver-3.txt dmesg-3.txt

Wait 60 seconds Power on monitor mate-screensaver-4.txt dmesg-4.txt

Wait 9 seconds (that's how long it takes monitor to boot) Can see and use screen/type/etc; it is (effectively) unlocked. dmesg-5.txt

(there is no dmesg-1.txt or dmesg-2.txt or mate-screensaver-5.txt (blank during that time))

Troubleshooting

This occurred on two machines.

Please let me know what other logs/steps may be useful.

MATE general version

1.20.0

Package version

mate-screensaver 1.20.0-1 See attached mate-packages.txt for full list of all mate-related package versions

Linux Distribution

Ubuntu 18.04

Downstream bug link

https://bugs.launchpad.net/ubuntu/+source/mate-screensaver/+bug/1768352

fizzfaldt commented 6 years ago

May be related to #152 and/or #126

fizzfaldt commented 6 years ago

I've placed a bounty on this; how do I get the bounty label added? https://www.bountysource.com/issues/57823146-mate-screensaver-screen-lock-can-be-bypassed-by-power-cycling-monitor

raveit65 commented 6 years ago

I have also several reports open at redhat Bugzila about problems with locking the sceen. https://bugzilla.redhat.com/show_bug.cgi?id=1397900 https://bugzilla.redhat.com/show_bug.cgi?id=1566571 https://bugzilla.redhat.com/show_bug.cgi?id=1470306 https://bugzilla.redhat.com/show_bug.cgi?id=1474046 https://bugzilla.redhat.com/show_bug.cgi?id=1497930

phocean commented 6 years ago

@raveit65 The issue #158 I opened looks very similar to yours.

Also, added to the bounty.

oz123 commented 6 years ago

Does someone knows if this affects also earlier versions of mate-screensaver?

oz123 commented 6 years ago

Also, maybe mate-screensaver should be completely archived? I have now switched to xscreensaver after reading this https://www.jwz.org/xscreensaver/toolkits.html

phocean commented 6 years ago

xscreensaver has a security history that does not make it ideal. I believe it would be better managed by the display manager.

oz123 commented 6 years ago

@phocean, can you please refer to links? Better explain?

phocean commented 6 years ago

I lost faith in the utility with CVE-2015-8025:

https://bugzilla.redhat.com/show_bug.cgi?id=1274452

I don't want my security to depend on a single utility that may segfault for various reasons, leaving the computer unlocked.

There is also an issue with most lockers on Linux : when you wake up your computer from suspend, it would show your desktop for about 1 second. Enough for a motivated attacker to take a photo of confidential data, for instance, or even trigger a mouse click (mouse event work during this period).

This is just one of the many reports you can find on Internet:

https://bugzilla.redhat.com/show_bug.cgi?id=713640

Having a secure locking infrastructure is far from trivial, much more complex than it seems at first.

To my knowledge, only Gnome 3 with gdm managed to do something quite robust (modulo the screen flash issue).

The idea is that I don't want my locking session to depend on a simple X program.

If there is a segfault, like in the DM, I would prefer it crashes my entire session if it has to, so that it gets never unlocked by an attacker.

Anyway, I believe such an architecture will be a requirement for Wayland.

oz123 commented 6 years ago

@phocean you have referenced one problem with xscreensaver, while both gnome-screensaver and mate-screensaver (which is based on the former) have far more known CVEs ... Also, the issue described here is a variant of the same issue you linked to. However the issue you linked to is fixed, while the issue here isn't. I also believe the issue described here will affect gnome-screensaver due to their shared histroy, but I am not going to spend time proving this, because I don't have the time nor the interest to invest in GNOME.

phocean commented 6 years ago

@oz123 sure, I am not asking anything: you asked, I just explained. The fact is that locking a screen with a X11 screensaver utility is outdated and will keep causing issues.

Can't it be addressed without coding?

Regarding this issue, I managed to get something much more robust, and with a lower attack surface (fewer LoC) with xss-lock and slock (or i3lock).

lukefromdc commented 6 years ago

This sort of thing is another example of why when security REALLY counts, a machine should be turned all the way off (poweroff and not hibernated nor suspended) when not in use. This is mandatory when encryption is relied upon, and apparently important the rest of the time too. Any application written in any language can have bugs, especially when it may be compiled many ways and run in many distros. X screensavers in particular have issues bad enough that Wayland devs cited them as a reason for moving away from X altogether.

This can be a real pain in the backside, so if anybody does manage to harden any screenlocker to the point that a serious, determined attacker can't recover your session, that will be worth a lot of saved time to a lot of people who are not using encryption, or who are in an environment where coworkers would not have long enough unsupervised access to attack encryption but might be able to sit at the machine long enough to power-cycle a monitor, suspend and restart(though this is reported to have the opposite problem), or execute a similar quick procedure.

phocean commented 6 years ago

@lukefromdc I don't get your point, even though I am aware of these facts (and that is probably not the place for a discussion).

The generic considerations you mention are not a valid reason to not harden the locker security.

It took my collegues less than one minute to get a remote shell on my machine while I was just going to the restroom. Do not tell me that I should have turned off my computer in such a circumstance...

Meanwhile, Windows goes as far as disabling DMA while the computer is locked...

So, I am still convinced that using the DM is a much safer approach, so at least an unexpected crash takes also the session down.

lukefromdc commented 6 years ago

According to https://linux.slashdot.org/story/15/01/28/1520252/why-screen-lockers-on-x11-cannot-be-secure all screenlockers on X are actually only emulating screen locking. What they do is to draw their own fullscreen window over everything else and try to catch all keyboard and mouse input(latter part is really critical), but the problem is that Xorg itself does not treat the screenlocker as anything more than just another app.

Still, this should not mean everything else gets drawn on top of the screenlocker or that it stop drawing at all, rather it's probably why so many X screenlockers show the desktop and applications for a second or so before finally rendering the lock screen on top of them.

Three years ago, t he KDE folks put a lot of effort into hardening their screenlocker and plugging two nasty bugs, but then turned around and published this blog post with a lot of details about the limitations of Xorg screenlockers: https://linux.slashdot.org/story/15/01/28/1520252/why-screen-lockers-on-x11-cannot-be-secure

Google is offering this screenlocker designed to be as secure as they can get it: https://github.com/google/xsecurelock

As I have said elsewhere, I only have encrypted machines that must be shut down when unguarded, which is why I don't normally run a screenlocker but when someone has code up that might fix this I can build and test it. I don't have the experience in screenlockers to write this myself, having not poked around the app's code and familiarized myself with it like I have with Caja, mate-panel, the applets, etc.

@raveit65 , @monsta, @sc0w,@vkareh, any ideas for this?

EDIT: This is a really ugly bug, as the poster reports the lock screen stays down with this trivial attack

EDIT2: The KDE folks also found as discussed in the second link that making screen locking a compositor task makes it much more secure, but of course in MATE we support multiple window managers. Still, we could implement some of that in Marco, and use a runtime check to see if Marco is running to use that codepath, and use the existing codepath with a security warning given if compiz or another WM is being used. Ideally that would also be ported to compiz-reloaded, perhaps as a plugin.

phocean commented 6 years ago

@lukefromdc thank you for the interesting pointers.

However, I disagree with your point with encryption. I work in infosec, so for sure my disk is encrypted too, plus secure boot, disk password and a few custom stuff... it just does not address the same threat at all.

You may not need it for your use case (are you working at home?), but for sure many people need a strong screenlocker.

raveit65 commented 6 years ago

I tried to reproduce https://bugzilla.redhat.com/show_bug.cgi?id=1566571 yesterday with my notebook (fedora 28) and a external monitor. But i couldn't reproduce the issue with display-power off and suspend-to-ram. My results:

- MATE is built from master (developing branch)
- using a second monitor, plugged in via hdmi port to my notebook
- a) screensaver bump in after 1 min
- b) display power off after 5 min.
- c) suspend-to-ram after 10 min

Ending a) state gives me the lockscreen-dialog on notebook display and second monitor shows the screensaver.

Ending b) state gives me the lockscreen-dialog on notebook display and second monitor shows a black screen.

Ending c) state gives me the lockscreen-dialog on notebook display and second monitor shows a black screen.

I get same results if the external monitor is the primary-monitor. 

I will try again with powering off or unplug the external monitor. This was here the problem, right?

@lukefromdc I think all of this is handled by systemd on modern distros. And i agree with you this needs to be fixed.

A girlfriend of mine use a mac notebook and she never shutdown her mac. She only use 'lid-close`, to power on/off their system. Sadly i think this is the common use of a notebook from a typical users, who don't care about what is inside their box , nowadays.

raveit65 commented 6 years ago

Btw. here is another locker , but last commit was from 2017 -_- http://www.webupd8.org/2013/07/light-locker-new-session-locker-for.html https://github.com/the-cavalry/light-locker

lukefromdc commented 6 years ago

Since the origjnal poster simply specifies "monitor" and not a particular monitor, I think this is about power-cycling the PRIMARY monitor, which would make this a desktop-only bug. A laptop would be OK as its monitor cannot be power cycled, but an office full of desktops running MATE would leave each workstation vulnerable to everyone else in the office once it got out that turning the monitor off and back on gave access. This is so simple it is guaranteed to be found by accidend in a large enough office.

lukefromdc commented 6 years ago

According to https://github.com/mate-desktop/mate-screensaver/issues/145#issuecomment-401382756 some lockers use a vt switch to avoid the mess of having to draw over everything else and thus close some of the worst X screenlocker holes. EDIT: Light-locker was apparently written at least in part to fix an issue with the screensavers than commonly used with lightdm that it was possible from the locked screen to Ctrl+Alt+F7 back to the unlocked desktop.

raveit65 commented 6 years ago

I was able to reproduce the issue with my main box with nvidia-graphic and using one monitor at display-port.

  1. Locking the screen with panel applet
  2. Power off/on (using the physical switch) my monitor.

But it isn't a clear reproducer, sometimes i had access to my desktop without a lockscreen-dialog, sometimes the dialog displays well. ......i hate such issues....

I think this gsettings key from mate-power-manager has an influence on this problem.

[rave@mother ~]$ LANG=C
[rave@mother ~]$ gsettings describe  org.mate.power-manager sleep-display-ac
The amount of time in seconds before the display goes to sleep when the computer is on AC power.
[rave@mother ~]$ gsettings get org.mate.power-manager sleep-display-ac
2100

Because with changing the value for this key i could trigger the issue again.

I used those commands to debug mate-screensaver and mate-power-manger.

killall mate-screensaver && mate-screensaver --debug
killall mate-power-manager && mate-power-manager --verbose

Screensaver logs were interesting. In both cases they look very similar and the lockscreen-dialog seems to be running. I found those differences in logs. Log without visible lockscreen:

[unfade_idle] gs-manager.c:1224 (13:25:25):  resetting fade
[gs_fade_reset] gs-fade.c:863 (13:25:25):    Resetting fade
[on_screen_monitors_changed] gs-manager.c:1581 (13:25:37):   Monitors changed for display :0: num=1
[gs_job_stop] gs-job.c:524 (13:25:37):   stopping job
[gs_job_stop] gs-job.c:528 (13:25:37):   Could not stop job: pid not defined
[gs_job_stop] gs-job.c:524 (13:25:37):   stopping job
[gs_job_stop] gs-job.c:528 (13:25:37):   Could not stop job: pid not defined
[gs_window_dialog_finish] gs-window-x11.c:1454 (13:25:37):   Dialog finished
[keyboard_command_finish] gs-window-x11.c:1318 (13:25:37):   Keyboard finished

Same with a working lockscreen.

[unfade_idle] gs-manager.c:1224 (13:35:39):  resetting fade
[gs_fade_reset] gs-fade.c:863 (13:35:39):    Resetting fade
[error_watch] gs-window-x11.c:1022 (13:35:49):   command error output: [request_response] mate-screensaver-dialog.c:136 (13:35:49):  got response: -2

[error_watch] gs-window-x11.c:1022 (13:35:50):   command error output: 

[error_watch] gs-window-x11.c:1022 (13:35:50):   command error output: (mate-screensaver-dialog:10204): GLib-CRITICAL **: 13:35:50.023: Source ID 19 was not found when attempting to remove it

[error_watch] gs-window-x11.c:1022 (13:35:50):   command error output: [do_auth_check] mate-screensaver-dialog.c:289 (13:35:50): Verify user returned: TRUE

[lock_command_watch] gs-window-x11.c:1589 (13:35:50):    command output: RESPONSE=OK

[lock_command_watch] gs-window-x11.c:1611 (13:35:50):    Got OK response
[gs_window_dialog_finish] gs-window-x11.c:1454 (13:35:50):   Dialog finished
[keyboard_command_finish] gs-window-x11.c:1318 (13:35:50):   Keyboard finished

So why Monitors changed for display :0: num=1 in bad log?

Full logs are here: https://www.dropbox.com/s/mtmnizud94i7ovt/locksreen-debug-bad-log?dl=0 https://www.dropbox.com/s/rhbd5g4he7xixk0/locksreen-debug-good-log?dl=0

raveit65 commented 6 years ago

I found a working workaround,.......using gnome-screensaver :smile: and i can't reproduce the issue any more with using gnome-screensaver. Instructions:

  1. Install gnome-screensaver from your distro package-manager.
  2. Disable mate-screensaver in mate-session-properties (no auto-start), uninstall is an option but not needed.
  3. Add /usr/bin/gnome-screensaver to auto-start
  4. Restart session
  5. Create a application-launcher for the panel with that command to look the session. /usr/bin/gnome-screensaver-command -l
  6. Controling g-s via dconf-editor or gsettings command-line. Gnome-screensaver use the same gsettings key for idle-activation than MATE.
    [rave@mother ~]$ gsettings get org.mate.session idle-delay
    1
    [rave@mother ~]$ gsettings describe  org.mate.session idle-delay
    The number of minutes of inactivity before the session is considered idle.

    Other keys for g-s:

    [rave@mother ~]$ gsettings list-keys org.gnome.desktop.screensaver
    picture-opacity
    logout-enabled
    lock-enabled
    logout-delay
    embedded-keyboard-enabled
    primary-color
    idle-activation-enabled
    secondary-color
    logout-command
    color-shading-type
    embedded-keyboard-command
    picture-options
    lock-delay
    show-full-name-in-top-bar
    picture-uri
    status-message-enabled
    user-switch-enabled

    That's enough for an office/gaming PC with one or 2 external monitors. Notebook users needs to patch mate-power-manager to have a working lock-screen with "lid-close" function. Simply renaming all occurrences of mate-screensaver to gnome-screensaver. A patch can be found here in this experimental branch for mate-power-manager. https://github.com/mate-desktop/mate-power-manager/commit/aa36d35d164046ab84c349b178ca8962355604fe I think user-switching function in lock-dialog will only work if you're using gdm as DM. Happy testing ;)

I looked in to gnome-screensaver git commit history for a solution for mate-screensaver, but no luck yet.

lukefromdc commented 6 years ago

I am about to test this with an initial test install from master, trying to invoke the bug, then checking the PR to see if it is fixed. This issue is world-class ugly, and any security feature that can by bypassed by power cycling is a dangerous trap for the unwary. This is nearly as bad as the Android 5 bug where a failed attempt to encrypt the fs exits silently and appears to have succeeded.

lukefromdc commented 6 years ago

I could not get mate-screensaver to show the unlocking dialog with lightdm (and GTK 3.23), and whether because of this or something else power cycling the primary monitor with the secondary monitor staying OFF had no effect. If I pressed a key on the keyboard I got my desktop image as used also as a lightdm background, but no lightdm greeter or other password unlocking option. Thus, I cannot directly test this but at least the PR built and ran, with same behavior here either way

raveit65 commented 6 years ago

@lukefromdc Weird, i am using also lightdm with slickgreeter as UI-frontend. But i don't think that this is related to DM. Are you shure that your screen is locked and do you see the selected screensaver theme, after you locked the screen with panel-lock-launcher? What value are you using for sleep-display depends if you are on battery or ac?

gsettings get org.mate.power-manager sleep-display-ac
gsettings get org.mate.power-manager sleep-display-battery

Edit: and is this key enabled?

[rave@mother ~]$ gsettings get org.mate.screensaver lock-enabled
true
lukefromdc commented 6 years ago

This was on a desktop, screen was locked and screensaver shown when locked from the main menu's panel-lock-launcher, just no login dialog ever. I have the gtk greeter in Lightdm

raveit65 commented 6 years ago

Without knowing your gsettings values for mate-screensaver and mate-power-manger it is very difficult to say what's going wrong. gsettings list-keys org.mate.screensaver gsettings list-keys org.mate.power-manager

You can send me your values per mail.

lukefromdc commented 6 years ago

For time reasons I have to give up on that for now, as it is another, separate issue with a program I do not normally use. I was hoping for a quick install and test of the issue under discussion but that did not work. I normally do not run mate-power-manager at all on the desktop and run it only on the laptop however, and keep all the settings for automatic behavior to "never" on all things.

EDIT: running or not running mate-power-manager had zero effect

sc0w commented 6 years ago

Fixed with https://github.com/mate-desktop/mate-screensaver/pull/167

raveit65 commented 6 years ago

@fizzfaldt @phocean @oz123 Any chance to test the fix for yourself before i do a new release? This is version for 1.20.x https://github.com/mate-desktop/mate-screensaver/commit/465734b765fcfa28a8b63a877bedd65cd2de959e

oz123 commented 6 years ago

I will be able to test it next week. Can you wait for that?

fizzfaldt commented 6 years ago

@raveit65 I'm out of town till September 5, i can try after I get back. Till then I only have a macbook

On Fri, Aug 24, 2018, 7:00 AM raveit65 notifications@github.com wrote:

@fizzfaldt https://github.com/fizzfaldt @phocean https://github.com/phocean @oz123 https://github.com/oz123 Any chance to test the fix for yourself before i do a new release? This is Version for 1.20.x 465734b https://github.com/mate-desktop/mate-screensaver/commit/465734b765fcfa28a8b63a877bedd65cd2de959e

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/mate-desktop/mate-screensaver/issues/155#issuecomment-415767769, or mute the thread https://github.com/notifications/unsubscribe-auth/ACnvoRL0fsprwf026KivH5GEeFy2Anzwks5uUAcZgaJpZM4Tuedp .

--

raveit65 commented 6 years ago

Np, i pushed this already to fedora to close open rhbz reports. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ab94a41797 https://bodhi.fedoraproject.org/updates/FEDORA-2018-f4c88b2bb5

oz123 commented 6 years ago

So, I finally got to test the fix. I can definitely say it does not work. I upgraded all mate components to the latest version, and I don't even have to cycle the screen. As soon as I pull the HDMI cable out of my laptop mate-screensaver crashed.

Here the trace from .xsession-errors:

(mate-screensaver:16561): Gdk-CRITICAL **: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed

(mate-screensaver:16561): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(mate-screensaver:16561): Gdk-ERROR **: The program 'mate-screensaver' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 975 error_code 3 request_code 131 (XInputExtension) minor_code 40)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
mate-session[16466]: WARNING: Detected that screensaver has left the bus

(mate-settings-daemon:16510): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -1 and height 1
oz123@yoni ~ $ mate-screensaver --version
mate-screensaver 1.21.0
lukefromdc commented 6 years ago

OK, I have some guesses about this. While I was not able to get mate-screensaver working on my box for still-unknown reasons, the problem reported in the above comment should not be too hard to stop. We have gdk_monitor_get_scale_factor getting a failed assert when a monitor no longer exists, so catching that might be a matter of checking to see if the monitor is still connected and exiting that function if it is not. Essentially run the same check as the assert, but as a conditional to exit the offending function and keep the screensaver running. Then make sure that reconnecting that monitor does not get a functional desktop displayed on that monitor.

I don't know if there is currently a function in mate-screensaver to watch for and catch appearance and disappearance of monitors, but if not that might be necessary to fix multimonitor issues.

Question: does power-cycling a single monitor on a desktop still unlock mate-screensaver for anyone?

raveit65 commented 6 years ago

@oz123 Sadly you didn't post which distro are you using?

oz123 commented 6 years ago

@raveit65, I am using gentoo.

raveit65 commented 6 years ago

Hmm, i am not really firm with packaging gentoo. But i tested it again with my notebook. Unplugging the external monitor at hdmi port several times doesn't crash the screensaver with fedora f28. The desktop is locked on both monitors. I tested this with MATE from master branch and MATE-1.20.x from fedora 28 repos + the fixed mate-screensaver version from updates testing https://bodhi.fedoraproject.org/updates/FEDORA-2018-f4c88b2bb5 So, i am still wondering why mate-screensaver-1.20.1 + the fix crashes for you. Can you asked your gentoo maintainer for confirming the crash?

oz123 commented 6 years ago

@raveit65 the gentoo maintainer is practically me. I have used the ebuilds from here. My system runs with all mate components built from the current master branch.

raveit65 commented 6 years ago

OK :) I thought Hardass ( or similar name) is the current maintainer.

raveit65 commented 6 years ago

Not sure if this causes the issue but building against systemd and consolekit is wrong. https://github.com/oz123/mate-de-gentoo/blob/master/mate-extra/mate-screensaver/mate-screensaver-1.20.1-r1.ebuild#L68 If you use systemd you should disable consolekit. See my spec file from fedora. https://src.fedoraproject.org/cgit/rpms/mate-screensaver.git/tree/mate-screensaver.spec

oz123 commented 6 years ago

@raveit65 np-hardass is missing practically. There are some people working on ebuilds for gentoo officially. I used their work to create my ebuilds. Also, I am compiling using:

$ equery u mate-screensaver
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for mate-extra/mate-screensaver-9999:
 U I
 + + X          : Add support for X11
 + + consolekit : Enable support for sys-auth/consolekit
 - - debug      : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
 - - gtk3       : Build with GTK+3 instead of GTK+2
 - - libnotify  : Enable desktop notification support
 - - opengl     : Add support for OpenGL (3D graphics)
 + + pam        : Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
 - - systemd    : Enable use of systemd-specific libraries and features like socket activation or session tracking

So it's only consolekit, it was configured with:

--with-console-kit --without-libnotify --without-libgl --without-systemd 
raveit65 commented 6 years ago

But why consolekit and not systemd? Consolekit is obsolete since several years, by all major distros. Sorry, i cant help with consolkit as i don't use it and i know nothing about.

oz123 commented 6 years ago

@raveit65 consolekit in gentoo is consolekit2. You know why systemd is not an option. If I was in the business of doing what everybody else does I was not writing you here. I'd be using gnome, won't I? ;-)

Also, I don't think this error has anything to do with systemd or consolekit (at least that is what I understand from the crash backtrace I posted above).

raveit65 commented 6 years ago

I love to control my box with systemd, using deprecated consolekit-1/2 isn't an option for me. And don't get this crash with 2 boxes with systemd.

Btw. Are you sure you applied https://github.com/mate-desktop/mate-screensaver/commit/762ae73b4aefcb943b4b573789ea25cbb9f4cbd5 correct?

Did you restart the box?

oz123 commented 6 years ago

I applied the patch. It's also in the current master. The ebuild simply pulls the git master and compiles it.

Good point regarding restart!

OK, I have since yesterday restarted my laptop, and currently I can't crash mate-screensaver by unplugging.

One issue which is still there yet, is that the screen flicker for a second, during this second the content of my desktop is shown. I tried a couple of times to capture the mouse and keyboard to prevent mate-screensaver from covering the whole screen. I failed (which is a good thing), but a I am afraid a more sophisticated tester would be able to somehow during this second kill mate-screensaver.

raveit65 commented 6 years ago

I am so happy that you could solve your local problem :)

lukefromdc commented 6 years ago

That momentary flicker has been called out as a security issue in X itself, as this is apparently a common problem in screensavers that draw over the other X windows. Details earlier in this thread at https://github.com/mate-desktop/mate-screensaver/issues/155#issuecomment-413542462 One workaround some other screensavers have resorted to is using a VT switch and intercepting efforts to ctrl-alt-F7 back to the desktop. Any flicker with that will be to a black screen, but it's a major rewrite.

joakim-tjernlund commented 6 years ago

@raveit65 , if MATE could support elogind too one could eventually dump consolekit2 Supporting elogind should just be a matter of changing the include prefix and linking against a different library.

raveit65 commented 6 years ago

@fizzfaldt @phocean Author of the commit which fixed the issue can't claim the bounty for personal reasons. Do you agree if i claim the bounty for MATE desktop team?

Btw. mate-screensaver-1.20.2 with the fix is released.

phocean commented 6 years ago

No problem for me, nice work! Thanks a lot !