This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 811385 - can't configure locking behaviour
can't configure locking behaviour
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kde-workspace (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-10 17:15 EDT by Karel Volný
Modified: 2013-08-01 07:40 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 07:40:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2012-04-10 17:15:15 EDT
Description of problem:
On various occassions, the screen gets locked and you have to supply user password before you can use the desktop. While this looks like a sane default, there are situations where it doesn't make sense, but it cannot be avoided.
This should be configurable.

Unfortunately, the one and only possibility to change this behaviour that I have found is in Power settings - Advanced, where you can turn off the lock on wakeup.

However, you cannot turn the lock off for the screensaver (a regression - I bet it was there in the past!) and for switching between sessions (or at least I haven't found how?)

Another thing is that you can set up the system in a way so that the user is logged in automatically / can log in without password. In this case, the default should be all locks off, as it doesn't make much sense to protect user's data this way, if "the attacker" can just simply restart X and have the user logged in without providing the password ...

Version-Release number of selected component (if applicable):
kde-workspace-4.8.2-3.fc17
Comment 1 Rex Dieter 2012-04-10 18:08:05 EDT
see
systemsettings->display&monitor->screensaver

So, screensaver implies screenlock (sorry if that's not obvious), and there is an option "Require password after: X seconds"
to allow one to come out of screensaver without a password for a brief amount of time.

Screen power management is independent of screen locking (as far as I know)

kdm autologin is broken, yes, known issue (I can dig up the open upstream bug if you want)

user switching does require password to resume a user session (maybe try a blank empty password?), I don't think there's any way around that.
Comment 2 Karel Volný 2012-04-13 04:27:10 EDT
(In reply to comment #1)
> see
> systemsettings->display&monitor->screensaver
> 
> So, screensaver implies screenlock (sorry if that's not obvious),

yep, it really is not (obvious)

> and there is an option "Require password after: X seconds"
> to allow one to come out of screensaver without a password for a brief amount
> of time.

ok, so how do I set "infinity" here?

- it goes up to 300 s only ...

> Screen power management is independent of screen locking (as far as I know)

which is a bit ... inconsistent

if you start screensaver, it locks, if you use dimming instead of screensaver, it doesn't lock?

what is so different between these two? - you can even treat dimming as a "show photos" type of screensaver where the "photo" is black men in a tunnel(*)

(*) hm, "black men in a tunnel" is a literal translation of a Czech saying about all-black photos - does that work in English?

> kdm autologin is broken, yes, known issue (I can dig up the open upstream bug
> if you want)

in which way is it broken? - it seems to work for me

> user switching does require password to resume a user session I don't think
> there's any way around that.

I just fail to understand what is here to resume?

- if I'm on a text console, and I'm switching using e.g. Alt-F4 and Alt-F5, once I log in on each of them, it doesn't require the password after switching again

- if I'm in X, and I'm switching using e.g. Ctrl-Alt-F1 and Ctrl-Alt-F2, it does not require the password each time

- if I'm in X and I'm switching from K-menu, it _does_ require the password

why?

what is so different that it can't be done without the password?

> (maybe try a blank empty password?),

no way - one of my usecases:

machine at my parents - only my father and my mother have physical access (plus anyone they allow to)

they do not hide anything, each of them can see the data of the other one, but they use two user accounts to have their environment customised, including different e-mail accounts etc.

so I want them to be able to switch as easily as possible

however, I can not allow empty passwords, as I need to connect to that machine via ssh to ocassionally fix something - I need to connect to their user accounts to fix it in their environment

and I can't use ssh keys as I connect from random computers, which are trustworthy enough to type in the password on ssh prompt, but not to store my private key on them

so, forcing my parents to type in strong password on each user switch is a big annoyance

I've taught them to use the Ctr-Alt-Fx way long time ago(*), but it results in a "support call" from time to time, as the session gets opened on another number than expected etc.

(*) hm, I also think that I've opened upstream bug about this years ago ... where is it?
Comment 3 Oliver Henshaw 2012-10-22 13:04:11 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > and there is an option "Require password after: X seconds"
> > to allow one to come out of screensaver without a password for a brief amount
> > of time.
> 
> ok, so how do I set "infinity" here?
> 
> - it goes up to 300 s only ...

Can't you untick the option? Or am I thinking of another configuration screen here?
Comment 4 Karel Volný 2012-11-06 10:20:16 EST
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > and there is an option "Require password after: X seconds"
> > > to allow one to come out of screensaver without a password for a brief amount
> > > of time.
> > 
> > ok, so how do I set "infinity" here?
> > 
> > - it goes up to 300 s only ...
> 
> Can't you untick the option? Or am I thinking of another configuration
> screen here?

well ... yes

with kde-workspace-4.9.2-3.fc17.x86_64

I believe it wasn't possible with the version discussed above

still I do not know how to turn off the password prompt when switching users from the menu
Comment 5 Fedora End Of Life 2013-07-03 23:43:05 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. 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 WONTFIX if it remains open with a Fedora 
'version' of '17'.

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 prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life.

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 6 Fedora End Of Life 2013-08-01 07:40:14 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.

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.