Red Hat Bugzilla – Bug 811385
can't configure locking behaviour
Last modified: 2013-08-01 07:40:14 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):
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.
(In reply to comment #1)
> 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
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?
(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?
(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
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
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.
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.