Red Hat Bugzilla – Bug 207966
gnome-screensaver does not activate during a typing break
Last modified: 2015-01-14 18:19:53 EST
Description of problem:
When the typing monitor forces a typing break, the screensaver cannot lock the
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. configure smart card to lock when it is removed
2. configure typing break for some interval
3. when typing monitor forces a break, remove smart card
screensaver does not activate. when the typing break is over, only the
application with focus is usable.
screensaver should activate.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
This is still a problem on Fedora 11 Beta / Rawhide 2009-05-04.
There should be a way to lock the screen automatically when a typing break is enforced. After all, the point is that you should walk away from your computer, and walking away from an unlocked computer isn't a great security practice.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. 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 '9'.
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 9'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 9 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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.
The process we are following is described here:
This is still a problem on fedora 11. Someone with permissions: please update the version affected so this isn't automatically closed.
I see this issue as well.
ctrl-alt-L does work OK.
but inactivity does not activate the screensaver after one minute as I set stuff.
Created attachment 350141 [details]
Anything wrong in the log?
gnome-screensaver-2.26.1-3.fc11.x86_64 now, no change
Re: Comment #4, Comment #5, Comment #0
Do you need the "smart card" mentioned in Comment #0 to reproduce this
issue? Comment #0 has
> Steps to Reproduce:
> 1. configure smart card to lock when it is removed
> 2. configure typing break for some interval
> 3. when typing monitor forces a break, remove smart card
If not, what is the procedure you used to reproduce this issue in F11?
No, I do not need the smart card.
(simplified) Procedure to reproduce in f11:
1) In GNOME, click preferences, then keyboard
2) click typing break tab
3) Enable, set typing break to 1 minute
4) wait 1 minute
5) observe that the screensaver is not activated, nor is a password required upon end-of-tpyingbreak
Also, it only greys out the first (in my case, of two) monitors. You can still use the second monitor. This is filed separately as bug 448077, but I believe it would also be fixed if the typing break simply activated gnome-screensaver (which works properly on multi-head setups).
I am not using a smartcard. Just plain keyboard and mouse.
if nothing happens with this bugreport, can we please at least somehow confirm that the root cause is NOT gnome screensaver?
Definitely not gnome-screensaver. It's an inherent bug in the way X works. Two apps can't have a grab at the same time. typing break takes a grab, gnome-screensaver needs a grab to work.
Hard to solve problem without some infrastructural changes that aren't likely to happen for some time (One idea we've thrown around is moving lock screen to a different X server [gdm in "factory" mode]).
I'm going to close this CANTFIX right now, because it's going to be a while before a viable solution is implemented.
Please suggest working alternative screensaver as this situation is a gaping security hole.
Please describe non-gnome-screensaver parts that need fixing.
Please describe with enough detail what needs fixing and why so that it can be fixed indeed.
Optionally: Please explain why it doesn't work on my system yet it apparently does on other peoples' systems.
I don't think there are currently any screensaver implementtations that can work this way. If a screensaver did work, then it would be working without taking a grab, so it wouldn't be securely locked.
I guess a screensaver could be written that takes a "server" grab instead of a mouse and keyboard grab, but then your network connections would get cut while the screen is locked because single threaded apps would be blocked on the first X call they do until ungrab.
One way to fix this issue is to integrate typing break and gnome-screensaver. That way they aren't both competing for the same grab. Instead, the screensaver would come on and not let you unlock until typing break is over. That kind of integration would need to be filed as an upstream bug report at bugzilla.gnome.org
Another way to fix this issue, I metnioned in comment 13. GDM (the login screen) has this concept of "factory" mode that we don't enable by default. If we did enable it by default, then gnome screesaver could defer to it for the lock screen dialog.
Another option would be for X to provide an extension that lets one client forcefully take grabs from another client.
Another option would be for X to provide a different mechanism for securing the keyboard, mouse, and screen specifically for screensaver applications that didn't involve grabs.
This issue will be eventually fixed, but it's not going to get fixed in the near term.
a) it worked
b) it ships as a default for gnome installs
c) now all of a sudden it is a problem
d) assuming proper management
e) how come?
ps: *what* way? why is this way necessary? do we need http://ubuntuforums.org/showthread.php?t=195557 ? do we understand the gaping security issues because of this? do we understand the picture that gnome reaffirms this way? See https://bugzilla.gnome.org/show_bug.cgi?id=47948 .
i would like this bug to block fedora 12.
yes. I mean this. even the most basic things go wrong.
btw: description of 'gnome-screensaver does not activate during a typing break' does not properly describe the situation you try to explain.
I don't see how this could have ever worked for gnome-screensaver or xscreensaver modulo security bugs in those programs. For the same reason the screen doesn't lock when a menu is sitting open.
X has this concept called "grabs". There are three types of grabs:
1) Keyboard Grabs
2) Pointer Grabs
3) Server Grabs
A "grab" means that all events on the display go to one program. So if a program has a pointer grab, then it will get mouse events even if the mouse is used on a part of the screen that the program isn't covering.
Likewise, if a program has a keyboard grab, then it will get all key presses even if the program doesn't have focus.
If a program has a server grab, then all programs but that program are frozen until that program with the server grab ungrabs.
Typing break takes a keyboard grab (and maybe a pointer grab, not sure) so when you type the key presses get ignored.
Screensaver takes a keyboard and pointer grab for security reasons. Those grabs are what effectively make the screen "lock". Without them you could hit alt-tab while the screen was locked and change focus to another application and start using it.
Since both apps want grabs, if one is running the other won't be able to get grabs. Screensaver refuses to lock if it can't get grabs because showing a locked screen that you can alt-tab out of is irresponsible. This is a long standing issue and it won't get fixed for F12.
It is a known issue that will eventually be addressed, though.
Note, as soon as the typing break is over the screensaver should immediately lock because it will keep retrying to lock until the pointer and keyboard are available to grab.
Appreciate your super clear explanation! Now it made sense to me.
Re: Comment #15
> One way ... is to integrate typing break and gnome-screensaver.
This makes a lot of sense to me.