| Summary: | keyboard/mouse grabs prevent screensave from starting | ||
|---|---|---|---|
| Product: | [Unmaintained] ksmserver | Reporter: | Stephen <medic> |
| Component: | lockscreen | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | 3nkript, amrecio, bernhard, bugs, bugzilla, habeckb033, i9i7soft, jmayer, kdebugs, l.lunak, mgraesslin, mwoehlke.floss, olivier, robertg.123, ruiz, stasnel, winter |
| Priority: | HI | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Stephen
2004-04-01 18:38:57 UTC
*** Bug 77991 has been marked as a duplicate of this bug. *** *** Bug 86935 has been marked as a duplicate of this bug. *** *** Bug 124283 has been marked as a duplicate of this bug. *** *** Bug 189668 has been marked as a duplicate of this bug. *** *** Bug 176637 has been marked as a duplicate of this bug. *** I can confirm the problem. For Debian Lenny (with KDE 3.5 and our e35 client) or Etch on a KDE desktop, if you keep the mouse within an open menu, the screensaver will not start. This is a security problem as the machine does not get locked if a person leaves the desk for a while. How to reproduce: Enable the screensaver with password requirement (e.g. 1min and 5 sec). Go to a menu and open it with the mouse and keep the mouse there. Just wait. Nothing happens. This works with the KDE start menu as simplified test-case. why did you assign that to allen? even more so without ensuring that the default tracker address (which is being watched) stays in the loop? @Oswald: Because if nobody is going to fix this, Allen will do it - so I have assigned it to him. Sorry for not keeping the list in the loop - I did not know this custom. Can you assign it to Allen and keep the list in the loop as necessary? Thanks! would you bet that allen will fix it? ;) anyway, i think the current cc: setup is just fine. @Oswald, yes I am pretty sure Allen will fix it - the question is only when he will do it. (Background: My company Intevation is a partner of KDAB and together we do paid work on KDE and the Kolab Client. This is a security related issue and we like to get it fixed.) well, then i should mention that this is a rather fundamental problem. either you find a way to steal grabs (maybe the extension which controls the alt-ctrl-numpad-slash/asterisk provides that), hack around it by sending close events to popup windows, or implement the locker by opening a new x server and disabling virtual terminal switching (gdm wants to go the latter route in the middle run). I can confirm this still happens in KDE SC 4.6.4. It's been already said but I must stress that, in my humble opinion, this is a fundamental security issue that should be given more attention. I've upgraded severity and priority. Alvaro, thanks for testing this. (The situation changed in that I cannot promisse and work of Allen on this right now.) *** Bug 334051 has been marked as a duplicate of this bug. *** *** Bug 203649 has been marked as a duplicate of this bug. *** I'm happy to announce that the upcoming Plasma 5.5 comes with a Wayland session which does no longer expose this sever issue. As the problem described in this bug reports is unfixable with X11, I consider this bug as fixed on Wayland. *** Bug 358859 has been marked as a duplicate of this bug. *** *** Bug 373235 has been marked as a duplicate of this bug. *** *** Bug 439416 has been marked as a duplicate of this bug. *** |