Bug 1015457 - Resuming a hibernated system in KDE does not ask for user's password (SECURITY flaw)
Resuming a hibernated system in KDE does not ask for user's password (SECURIT...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: kde-workspace (Show other bugs)
20
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-04 06:10 EDT by Dr. Tilmann Bubeck
Modified: 2015-06-29 08:32 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 08:32:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dr. Tilmann Bubeck 2013-10-04 06:10:08 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):
kde-workspace-4.11.1-3.fc19.x86_64

How reproducible:
Always

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.
 
Actual results:
After resume you will get a system without requiring password.

Expected results:
Ask for password after resuming

Additional info:
Comment 1 Daniel Vrátil 2013-10-04 07:26:59 EDT
Could you please verify whether in System Settings -> Power Management -> Advanced Settings, the option "Lock screen on resume" is checked?
Comment 2 Rex Dieter 2013-10-04 08:14:10 EDT
note:

> 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?

Also:

> 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.
Comment 3 Dr. Tilmann Bubeck 2013-10-04 10:27:57 EDT
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.
Comment 4 Kevin Kofler 2013-10-08 17:52:20 EDT
I think the issue here is that ksmserver simply does not expect hibernating to require user interaction.
Comment 5 Lukáš Tinkl 2013-12-06 13:29:58 EST
... or this may very well be another dupe of the heisenbug, https://bugzilla.redhat.com/show_bug.cgi?id=983110
Comment 6 Dr. Tilmann Bubeck 2014-05-18 17:25:51 EDT
Still present in fedora 20...
Comment 7 David Jones 2015-02-15 15:35:21 EST
This sounds very similar to the bug I reported in 1191811, and may be related. I'm also running Fedora 20.
Comment 8 Fedora End Of Life 2015-05-29 05:30:46 EDT
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'
of '20'.

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.
Comment 9 Fedora End Of Life 2015-06-29 08:32:36 EDT
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.