With IM modules it's possible that one cannot unlock the screen at
all. So better disable all IM modules in the greeter. For that we
explicitly enforce the compose module, which is the fallback in Qt.
BUG: 306932
FIXED-IN: 5.2.1
REVIEW: 122259
XFlush is not called automatically when going back to event loop, thus
events are not delivered. With the XFlushs at these two positions I'm
no longer able to reproduce the problem that the screen ends up black
instead of showing the lock windows.
When the system is going to sleep we want to ensure that the screen gets
locked before the system goes to sleep. Logind provides the inhibitor
locks which can be used for this.
If logind is available ksld gains an inhibitor lock for sleep when the
screen is unlocked. As soon as the screen gets locked the inhibitor lock
is released. In addition it connects to the prepareForSleep signal by
logind and locks the screen.
The solution needs to be extended to have a config option whether the
screen should be locked on sleep. Currently this is provided by
powerdevil. Also the solution can only work properly if power devil uses
logind's sleep dbus interface.
We only want to ensure that the greeter gets started. There is no
need to block for that. Instead we can connect to the error signal
and unlock in case the greeter failed to start.
The greeter installs a custom QQmlNetworkAccessManagerFactory which
creates QNetworkAccessManagers which do not have access to the
network.
Unfortunately this is not a 100 % secure way to disable network, any
plugin could change the factory again and thus enable network. This
is done for example by KDeclarative, so the greeter now first creates
KDeclarative and then sets the custom factory.
It is a sufficient solution to block all network access for pure
QtQuick without a binary package as we would find in a look'n'feel
package.
Network access needs to be blocked in the greeter as otherwise a
look'n'feel package were able to send the entered password (and other
information to the creator of the look'n'feel package.
REVIEW: 121847
The screenlocker_greet needs to tell the parent ksld process which
windows it created. Ksld sends input events to these windows. So
far this was based on an X property on the window. Unfortunately
ksld didn't validate whether the windows tagged with this property
belong to the screenlocker_greet process it started.
With this change the communication for announcing windows is moved
away from the X11 protocol and instead a custom Wayland protocol is
used.
Ksld starts a KWaylandServer when the greet process gets started. It
creates anonymous unix sockets for the connection and passes one
filedescriptor to the started greeter process.
The check for the X property is removed in ksld and instead only
windows ids passed through the Wayland socket connection are
accepted.
REVIEW: 121429
KGlobalAccel takes first shortcut in list as primary and other as
secondary shortcut, and KShortcutsDialog only allows to edit primary
shortcut, see bug https://bugs.kde.org/show_bug.cgi?id=341942
This result in problem where only Screensaver key is configurable and
Alt+Ctrl+L can not be removed. Someone will less likely use Screensaver
key for other purposes.
CCBUG: 336348
Reviewed-by: Marco Martin <notmart@gmail.com>
When the look and feel lockscreen theme failed to load for whatever reason,
it is supposed to fall back to a built-in theme to not lock the user out of the system.
The fallback did not work, however, and made the greeter crash with an invalid package
access, trapping you in an endless kscreenlocker_greet reboot loop.
REVIEW: 121333
Logging out from the locked screen is impossible. Logging out means
interaction with the session due to the session manager. The session
manager asks all applications to quit and applications are allowed to
ask for example saving changes. The session manager stopps the
logout in this case and asks the window manager to focus this window
and the session manager will only continue the logout once the
application resolved the situation. At any time in this process the
user is still able to abort the logout!
Switching to the application which needs interaction is impossible,
though as the screen is still locked. The result is a seemingly
frozen system as the logout cannot continue and there is no indication
what is going on.
Of course the lock screen cannot unlock the session for the logout as
that would circumvent the security. If the lock screen would unlock
one would just have to click the button and abort the logout really
fast to have the system unlocked. So this is clearly not an option.
The result is: we cannot implement this functionality in a working
and secure manner, so it's better to remove it.
REVIEW: 120577
BUG: 339453
FIXED-IN: 5.1.1
Martin Gräßlin
Alex Richardson
l10n daemon script
Montel Laurent
Elias Probst
Marco Martin
David Edmundson
Bhushan Shah
Kai Uwe Broulik
Pino Toscano
Lukáš Tinkl