kscreenlock_greet insecure with multiple X screens

[TJ]

When using multiple X screens (3 in this case), kscreenlocker-greet behaves very badly and insecurely.

It appears to be drawing the desktop background image/screensaver images for all three X screens to the primary screen (0) and doesn't blank/screensave the monitors belonging to screens 1 and 2 (which leaves their contents in view), and it displays 2, maybe 3 greeter dialogs (1 may be hidden) on the primary X screen, but only accepts typed password input in 1 of them (the primary X screen's dialog).

Reading the source-code at

 ksmserver/screenlocker/greeter/greeterapp.cpp::UnlockApp::desktopResized()

it appears to iterate the screens via desktop()->screenCount() but assumes there is only one X display when showing the ScreenSaverWindow.

There may be an underlying dependencies on the QT libraries that cause/affect this but someone familiar with the code would need to investigate it.

[Alexey Shvetsov (alexxy)]

If you have 2 videocards e.g.
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Turks [Radeon HD 6670]
02:00.0 VGA compatible controller: NVIDIA Corporation GF106 [GeForce GTS 450] (rev a1)

And configured two screens e.g. :0.0 and :0.1 locker-qml will lock only one screen

Reproducible: Always

[Adam Ziegler (mrbond)]

Can confirm the same behavior with two X screens across two nVidia cards - GTX 460 and GTX 465. Lock screen appears over X screen 0, leaves X screen 1 untouched, but I can't do anything on either screen (as I would expect).

May or may not be related, but I also cannot get focus to the password field, so once the screen is locked, I need to hard-reset kdm to get back to a workable session.

[Jens Mohr (jens-homejm)]

The same here:

- KDE 4.10.1
- two separate screens
- only one screen will locked the other show the session!

When i click the unlock button and wait then i get the focus to the password field.

[Jens Mohr (jens-homejm)]

KDE 4.10.2

no changes!

- two separate screens - only one screen will locked the other show the session! When i click the unlock button and wait then i get the focus to the password field.

[Harald Sitter (apachelogger)]

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. While we appreciate your issue, it would be better if it was tracked at https://bugs.kde.org, so that the KDE developers can deal with this speedily and have direct communication with you as the reporter for more effective debugging.

Thanks!

[TJ (tj)]

Attaching photographs demonstrating the issue

[Kde-1 (kde-1)]

When using multiple X screens (3 in this case), kscreenlocker-greet behaves very badly and insecurely.

It appears to be drawing the desktop background image/screensaver images for all three X screens to the primary screen (0) and doesn't blank/screensave the monitors belonging to screens 1 and 2 (which leaves their contents in view), and it displays 2, maybe 3 greeter dialogs (1 may be hidden) on the primary X screen, but only accepts typed password input in 1 of them (the primary X screen's dialog).

Reading the source-code at

 ksmserver/screenlocker/greeter/greeterapp.cpp::UnlockApp::desktopResized()

it appears to iterate the screens via desktop()->screenCount() but assumes there is only one X display when showing the ScreenSaverWindow.

Reproducible: Always

Steps to Reproduce:
1. Configure multiple X screens
2. Lock
Actual Results:
All background images and screensavers are drawn to X screen 0

Expected Results:
Each background image and screensaver should be rendered on the correct X screen

I'm testing a possible fix which passes display()->screen(i) to the QDeclarativeView constructor.

Photographs of the screens are attached to the referenced Ubuntu bug report #1264821.

[TJ (tj)]

I've developed a fix which I'm currently building and testing.

[TJ (tj)]

The attached patch is tested and fixes the bug on v4.10.5 and similar. The base code using QDeclarativeView was significantly re-factored on 22nd October 2013 for the Plasma 2 Technology Preview release (commit tag plasma2tp) dated 19 December 2013.

I am developing a patch for upstream Plasma 2 separately since it requires new considerations and testing.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Render background and greeter on correct X screens" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[TJ (tj)]

The attached patch applies to Trusty 14.04 (kde 4.11.4).

[Kde-1 (kde-1)]

Created attachment 84383
Render background and greeter on correct X screen

This patch is for version up to 4.11.4.

The re-factoring for Plasma 2 needs a little more research since it replaces QDeclarativeView with a QQuickView, but the same solution (passing QApplication->display()->screen(i)v) looks to be doable if the QWidget is exchangeable for the QWindow in the QQuickView constructor.

[Mgraesslin (mgraesslin)]

are you really using multiple X screens like :0.0 and :0.1?

[Kde-1 (kde-1)]

Don't forget :0.2!

[Mgraesslin (mgraesslin)]

ok, so it is multi-head.

This is a very uncommon setup and I doubt any developer is able to test and verify the patch. From a quick look at the patch looks wrong to me, because you use "i" as an index in QDesktopWindow::screen(). This looks crashy to me and potentially wrong. In fact in your case I expect that it's always just 0. There should be three processes with one screen each. While on a more regular setup there is just one process with three screens attached.

[Joe (valsacar-8)]

I'm also being hit by this bug, any progress? I just upgraded from 12.04 to 14.04 and decided to try out KDE. I have 3 monitors, my left two are X1 and my right most is X0 (primary). When I lock the screen, X0 locks (but the password box appears halfway off the right side of the monitor, as if it was a screen spanning 2 monitors) and the other two still display whatever was on my screen at the time.

[Mgraesslin (mgraesslin)]

Unfortunately multi-head support is not implemented in the lock screen infrastructure and I consider it as unlikely that we will implement it any time soon. It's nowadays difficult to configure (some drivers do not support such modes any more) and it needs significant changes in our lock screen architecture to support it. Changes I plan for 5.3 might make it easier to support such setups in a secure way.

[Mgraesslin (mgraesslin)]

*** This bug has been marked as a duplicate of bug 314073 ***

[Mgraesslin (mgraesslin)]

*** Bug 329375 has been marked as a duplicate of this bug. ***

[Mgraesslin (mgraesslin)]

*** Bug 314533 has been marked as a duplicate of this bug. ***

[Mgraesslin (mgraesslin)]

In a multi-head setup do you have two ksmserver instances?

[jcwoods (jcwoods-gmail)]

In my case, it does not run two instances of ksmserver. I have a single instance, and the environment (from /proc/<pid>) indicates that it is pointed to DISPLAY :0. My two displays are configured as :0.0 and :0.1, and the lock screen actually runs on :0.0.

[desktop:~]$ ps -elf | grep ksmserver
0 S xxxxxx 4273 4130 0 80 0 - 1082 unix_s Nov04 ? 00:00:00 kwrapper4 ksmserver
1 S xxxxxx 4274 4233 0 80 0 - 138946 poll_s Nov04 ? 00:00:09 kdeinit4: ksmserver [kdeinit]
[desktop:~]$ cat /proc/4273/environ | tr '\0' '\n' | grep DISPLAY
DISPLAY=:0
[desktop:~]$ cat /proc/4274/environ | tr '\0' '\n' | grep DISPLAY
DISPLAY=:0

[Mgraesslin (mgraesslin)]

This will make it difficult. Ksmserver has to render the screen black and it looks like it doesn't have access to all X servers.

I'm afraid that this might be a problem which we won't fix any time soon. It will require quite some reworking on assumptions in the lock screen interaction.

[U26 (u26)]

We no longer support multiple screens.