Red Hat Bugzilla – Bug 1015457
Resuming a hibernated system in KDE does not ask for user's password (SECURITY flaw)
Last modified: 2015-06-29 08:32:36 EDT
Description of problem:
Selecting "Hibernate" in KDE results in a hibernated image which will restart to the user's desktop without asking a password.
After selecting "hibernate" from the KDE menu as a normal user, the system asks for root permission to continue. However, this dialog is only shown for a fragment of a second and the users screen locker appears above it. The system does not hibernate. The user typically then enter its password into the screen saver and returns to the desktop seeing the previous dialog asking for root permissions to hibernate. After entering the root password, the machine hibernates and switches off. After turning power on and resuming, the users desktop is shown without asking a password. Probably because I entered the password into the screen saver right before hibernating.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log into KDE
2. Select "Hibernate" from KDE menu
3. Enter your user password into screen saver
4. Enter root password into dialog asking for hibernate permission.
After resume you will get a system without requiring password.
Ask for password after resuming
Could you please verify whether in System Settings -> Power Management -> Advanced Settings, the option "Lock screen on resume" is checked?
> 4. Enter root password into dialog asking for hibernate permission.
This is not usually required, but is likely occurring because there are other active users on the computer at the time of hibernate action being requested. Can you verify if this is the case?
> 3. Enter your user password into screen saver
I suspect this is likely the confusion here. *This* is the lock screen you want. Seems hibernate is happening too slow on your system, giving you enough time to unlock before hibernate actually finishes.
In (In reply to Dan Vrátil from comment #1)
> Could you please verify whether in System Settings -> Power Management ->
> Advanced Settings, the option "Lock screen on resume" is checked?
Yes, "Lock screen on resume" is checked.
I think in preparation for suspend KDE does two things in parallel:
a. Ask for root permission to do the hibernate
b. lock the screen in preparation for resume due to the above settings.
However, because of b. the user is unable to answer a. So therefore he unlocks b. by giving his password. Then he sees a. and allows the suspend. Then the machine suspends and b. is actually already opened.
So if I am right, I propose to start with a. and only if the permission to suspend is granted it should actually suspend and start b.
In (In reply to Rex Dieter from comment #2)
I booted the machine, logged into KDE and selected "hibernate". No one else is logged in and nothing else has been done.
And it is not a question of speed (neither user nor system). If I wait a few minutes between my actions nothing changes.
I think the issue here is that ksmserver simply does not expect hibernating to require user interaction.
... or this may very well be another dupe of the heisenbug, https://bugzilla.redhat.com/show_bug.cgi?id=983110
Still present in fedora 20...
This sounds very similar to the bug I reported in 1191811, and may be related. I'm also running Fedora 20.
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.