In Plasma 5.3 new effect was introduced when "Show desktop" action is triggered - panel is hidden and we see fragments of minimized apps in screen corner. Due to this effect when those apps fragments are rendered in screen mode we can see them also when screen is locked. This probably might be some security issue, as locked screen should hide whole desktop content. Reproducible: Always Steps to Reproduce: 1. Open some apps and trigger action "Show desktop" 2. You should see in probably in upper right corner some fragments of those apps due to new effect 3. Right click on desktop when in "Show desktop" mode 4. Pick from context menu "Lock screen" 5. When screen is locked we can see those apps fragments in upper right corner Actual Results: We can see fragments of minimized apps (due to new effect when showing desktop) in locked screen mode. Expected Results: Locked screen should hide whole desktop content.
This goes a bit beyond a particular effect - about any effect can elevate any window any time. @Martin If there's no particular reason to allow elevation while the screen is locked, I'd preferably go for inline QList<EffectWindow*> EffectsHandlerImpl::elevatedWindows() const { + if (isScreenLocked()) + return QList<EffectWindow*>(); return elevated_windows; } rather than relying on the client code to behave correctly.
I'm for both: client code behaving correctly and making core always having further safety guards. So +2 for that code snippet.
Git commit 89195c7e83f4d8be18fede81f14b69e5747b30e2 by Thomas Lübking. Committed on 15/05/2015 at 20:02. Pushed by luebking into branch 'Plasma/5.3'. ignore elevation list while screen is locked elevated windows would appear above the locker pot. leaking information M +2 -0 effects.h http://commits.kde.org/kwin/89195c7e83f4d8be18fede81f14b69e5747b30e2
(In reply to Martin Gräßlin from comment #2) > I'm for both: client code behaving correctly and making core always having > further safety guards. So +2 for that code snippet. This would require us to export the locked screen state (changes) to client code / scripts itfp. ;-) I wonder whether we should make rendering windows that are not the screen locker NOOP - this would implicitly secure the screenshot effect (instead of relying on it to be deactivated while the screen is locked) and about 99% of all information leaks?
Git commit 538ff0c8aa0de93fba67af94789477c1325e4e24 by Thomas Lübking. Committed on 15/05/2015 at 21:55. Pushed by luebking into branch 'master'. ignore elevation list while screen is locked elevated windows would appear above the locker pot. leaking information M +2 -0 effects.h http://commits.kde.org/kwin/538ff0c8aa0de93fba67af94789477c1325e4e24
(In reply to Thomas Lübking from comment #4) > I wonder whether we should make rendering windows that are not the screen > locker NOOP do we know which windows belong to the screenlocker on X11? On Wayland it'll be obvious but on X11? We cannot trust the data.
(In reply to Martin Gräßlin from comment #6) > do we know which windows belong to the screenlocker on X11? "Semi" - one could reason that it's safe to assume that if the greeter window (along the _KDE_SCREENLOCKER or whatever the exact property is) is present, all windows w/o that property are not the screenlocker. Oc. malicious SW could remove the property (and we're on the current status quo) or add it randomwhere (and the user has a black desktop ;-) but malicious SW can do a lot of malicious things itr, once it's running on your machine.
> once it's running on your machine. Which is not necessarily the case on X11, it might be a ssh-forwarded window... There is no security risk involved as the windows won't get input, but still it would render the system not unlockable.