SUMMARY If .config/kscreenlocker_greetrc is not writable (eg. due to emergency remount of the partition as read-only) and the user attempts to lock the screen, a dialogue containing: 'Configuration file "/home/leonard/.config/kscreenlocker_greetrc" not writable. Please contact your system administrator.' will popup and the system will freeze. It is not possible to close the dialog, neither does the lock screen show up. Logging in on tty and issuing `killall kdialog` closes the dialog. Switching back to X session, the lock screen shows up. Unlocking the system works fine. STEPS TO REPRODUCE 1. mount -o remount,ro /home 2. Lock screen OBSERVED RESULT System hangs with dialog message 'Configuration file "/home/leonard/.config/kscreenlocker_greetrc" not writable. Please contact your system administrator.' open. EXPECTED RESULT Screen is locked. Dialog with warning may/should be opened, but should not block screen locking process and cause system hang. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 4.20.2 KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.3 ADDITIONAL INFORMATION
https://phabricator.kde.org/D18291
Also, you may want to set KDE_HOME_READONLY in your environment if you use a read-only home, as I don't think this is a supported usecase.
Thanks Kai. I would argue that KDE_HOME_READONLY should not be required to avoid this freeze. Requiring KDE_HOME_READONLY means that a user must consciously want to run on a read-only system, which I guess is not very useful / common. But read-only remount due to kernel bug or cosmic ray is somewhat common, so KDE should still support users investigate and fix the root-cause if that happens. If KDE locks up the X Session, this makes debugging harder and may encourage users to force reboot their system, which in turn would make documenting and recovering from the kernel issue / bit-flip data corruption issue harder.
I see. I agree at least the lock screen definitely shouldn't lock the user out because of this, which is what my patch is for. Other than that I think it needs to be decided on a case-by-case basis how to address this.
Thanks Kai. Sorry if I misunderstood your previous comment as requiring the env variable.
Git commit 30e61b4aa4e73b0cc87cf26d78eb39d8eab8ce3d by Kai Uwe Broulik. Committed on 16/01/2019 at 14:10. Pushed by broulik into branch 'master'. [Greeter] Ignore unwritable configuration files When opening a non-writable config file, a kdialog process is spawned and the application waits for it to quit. However, since in case of the lock screen, the input and everything is already blocked, the user cannot dismiss the warning generated by the greeter, effectively locking the user out. Differential Revision: https://phabricator.kde.org/D18291 M +4 -0 greeter/main.cpp https://commits.kde.org/kscreenlocker/30e61b4aa4e73b0cc87cf26d78eb39d8eab8ce3d