Ubuntu

screen doesn't lock when some menu is open

Reported by Ben Scholl on 2006-06-13
This bug affects 129 people
Affects Status Importance Assigned to Milestone
GNOME Screensaver
Confirmed
Medium
OEM Priority Project
High
James M. Leddy
Precise
High
James M. Leddy
X.Org X server
Confirmed
Wishlist
gnome-screensaver (Ubuntu)
Low
Unassigned
Nominated for Quantal by James M. Leddy
Precise
Undecided
Unassigned
xorg-server (Debian)
Confirmed
Unknown

Bug Description

Binary package hint: gnome-screensaver

I'm running a fresh install of Dapper with screensaver set to 'blank screen', and 'lock screen when screensaver is active' enabled.

If a panel menu (e.g. Applications) is open and the machine is left idle, the screen fails to lock. It fades out after the time period as expected, but the desktop reappears after a few seconds.

Ben (comments / criticism welcome, this is my first bug report)

Simon Law (sfllaw) wrote :

Steps to reproduce:
1. System > Preferences > Screensaver
2. Select "Blank Screen" and set the timeout to 1 minute
3. Open the Applications menu
4. Wait 61 seconds.

Expected result:
The screensaver kicks in.

Actual result:
Nothing happens.

Changed in gnome-screensaver:
importance: Untriaged → Low
status: Unconfirmed → Confirmed
Changed in gnome-screensaver:
status: Unknown → Unconfirmed
Nikhil Fernandes (njfernandes) wrote :

I noticed this in Gutsy, so it hasn't been fixed.

Tristan Rhodes (tristanrhodes) wrote :

I just ran into this bug as well. I was browsing through the applications menu before I went to bed. When I checked it in the morning, the screensaver had not activated, nor did the monitor shut-off.

This could be related to this bug: 139405
https://bugs.launchpad.net/gnome-screensaver/+bug/139405

That bug also adds the case where you right-click on something and leave the menu open.

Martin Schaaf (mascha) wrote :

This is still an issue in intrepid.

Changed in gnome-screensaver:
status: Confirmed → Triaged

Hello,

when you open a menu of e.g. KDE konqueror, GNOME nautilus or firefox
then the screensaver wouldn't start in my tests. First I thought its
a KDE bug http://bugs.kde.org/show_bug.cgi?id=176637 but the same behaviour
can be reproduced with gnome.
Or if you open a pull down menu on a website with firefox/iceweasel the
screensaver will not start.
It is reproducible with installed gnome-screensaver and not installed xscreensaver so I think its not xscreensaver specific.

If xscreensaver is used you can see the following:

xscreensaver reported the following lines when the timeout expired:
xscreensaver: 20:16:02: couldn't grab keyboard! (AlreadyGrabbed)
xscreensaver: 20:16:06: couldn't grab keyboard! (AlreadyGrabbed)
xscreensaver: 20:16:10: couldn't grab pointer! (AlreadyGrabbed)
xscreensaver: 20:16:10: unable to grab keyboard or mouse! Blanking aborted.

The source code comment says:

xscreensaver-5.07/driver/xscreensaver.c
...
      if (! blank_screen (si))
        {
          /* We were unable to grab either the keyboard or mouse.
             This means we did not (and must not) blank the screen.
             If we were to blank the screen while some other program
             is holding both the mouse and keyboard grabbed, then
             we would never be able to un-blank it! We would never
             see any events, and the display would be wedged.

             So, just go around the loop again and wait for the
             next bout of idleness. (If the user remains idle, we
             will next try to blank the screen again in no more than
             60 seconds.)
          */

I don't know if opening a menu in an application grabs mouse and
keyboard.

this is answered by Michel in http://bugs.debian.org/514036

--8<-- Michel Dänzer <daenzer at debian.org>
It does; it's the only way the menu can receive input events while the
pointer is outside of it. AFAIK this is a pretty deep X11 design issue,
so I'm afraid this can't be fixed easily. Feel free to bring it up
upstream though.
--8<--

Sorry but I don't know which is the correct component for this topic.

Marc Gariépy (mgariepy) wrote :

The same behavior can also be produced when you press "CTRL+D" in firefox.

Way to reproduce :
1- open firefox
2- go to a webpage: http://launchpad.net/ (any have the same effect)
3- Press CTRL+D
4- do not close the bookmark page pop-up. It's not possible to lock the screen by waiting or pressing CTRL+L

If I can add a word, there are no clear logical connections between locking the screen and the screensaver. I don't use any screensaver but I still want to be able to lock the screen when I'm away so I was very surprised when clicking on Lock Screen produced no result. If that were worded Start Screensaver I would have understood, but I'd also have expected to see the screesaver start.

By the way, I'm on Jaunty and
$ dbus-send --print-reply --reply-timeout=100 --dest=org.gnome.ScreenSaver / org.gnome.ScreenSaver.Lock

gives:

Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.ScreenSaver was not provided by any .service files

which might be a hint to another problem. I can see the previews of all the installed screensaver but they never start even if I enable them.

HannesB (hannesb) wrote :

This is still an issue in karmic and it is causing another annoying behavior:
After the screensaver failed to start due to an open menu and I continue to work, the screensaver
immediately starts. Its annoying.
This bug could be similar to 388598, where an open menu prevents the hotkeys from working...

Peter Ford (peter.ford) wrote :

> This bug could be similar to 388598, where an open menu prevents the
> hotkeys from working...

Yes, I think so. See "gnome-bugs #440515", which is listed in the Remote Bug Watches section. That is the 'upstream' bug about the screensaver problem. Comment 7 on it implies there is a link between it and the 'global keyboard shortcut' problem.

I have the feeling that a proper fix may need a change to part of the design of GTK+. Perhaps someone should set up a software bounty? Alternatively, there was a workaround suggested just for the screensaver problem: a timeout for open menus.

tags: added: metabug
QPrime (mwells) wrote :

This may not add anything constructive to the thread, however I have also noticed that screen-fades/screen-locks are also inhibited when system modal dialogs (like Update Manager password authentication) are open.

Currently testing on an installed Lucid daily live (2010.02.18) with all updates applied.

Changed in gnome-screensaver (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
Jay (slater-jay) wrote :

I've also noticed that the screen doesn't lock in the following circumstance:

1. Open a right-click menu.
2. Suspend the machine.
3. Wake the machine.

The right-click menu will still be open, and the screen will not be locked.

Is this close enough to stay in this bug?

tags: added: lucid
Rafal-maj-it (rafal-maj-it) wrote :

For me, the screen does not fade out nor does it lock, only it shows the screensaver icon next to the clock.

security vulnerability: no → yes
Rafal-maj-it (rafal-maj-it) wrote :

This should be considered security vulnerability, leaving work station unlocked.

Changed in gnome-screensaver:
status: New → Confirmed

Step to reproduce the bug:
Right click to the desktop and wait. The screen won't lock. The monitor still display what happen in screen. When you click the mouse it will lock immediately

Changed in gnome-screensaver:
importance: Unknown → Medium
Alan (mrintegrity) wrote :

The worrying thing is that it doesn't lock the screen immediately.. there is a couple of seconds where a user could close a window or launch an application.. perhaps even a script from an automounted drive.. if the system is under a lot of load then the delay is even longer.

A clear security vulnerability that has gone un-addressed for years...

papukaija (papukaija) wrote :

"A clear security vulnerability that has gone un-addressed for years..." - That's what happens to all non high/critical bugs :(

tags: added: maverick
Sam Brightman (sambrightman) wrote :

This issue is also a problem when using synergy for input device sharing, or virtual machines (see https://bugzilla.redhat.com/show_bug.cgi?id=569830). In addition, there is a significant delay whilst the screen is locked, during which time input is still accepted and could be used maliciously. It is a security issue and should be fixed.

I think the attitude of the gnome-screensaver team is clear from their FAQ:

"Why doesn't my screen lock when I'm logged in as root?

gnome-screensaver will blank the screen but will not lock. This is for security reasons. Seriously, it is very unwise to login as root in the first place. Try logging in as an unprivileged user and using sudo or su instead. "

This is INSANE. Deliberately create an even bigger problem to force people to do things your way?!

papukaija (papukaija) wrote :

Deleted Redhat's bugwatch - it's not the upstream bug report of this bug.

papukaija (papukaija) wrote :

Has anyone tested if this bug goes away in Unity (either in Maverick UNE or any alpha of Natty)?

Sam Brightman (sambrightman) wrote :

If you read that Redhat bug - and specifically my comment on it - you will see that the title is misleading. It was probably wrongly closed when it was also being moved against gnome-screensaver (and should have been retitled).

Further, it probably IS the same bug as this - the underlying issue is with gnome-screensaver grabbing input devices. This manifests in several different situations.

Changed in gnome-screensaver (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody

I'm not clear that there is definitely a need for a keyboard grab to implement menus with access keys, even though that is what toolkits often do.

It may be convenient from the perspective that events are directed to the menu window.

But in most cases the main application window would have focus and so the application can receive keyboard events there.

If for some reason a client does not normally receive focus in the main window, I wonder whether it should negotiate keyboard focus (perhaps under the Globally Active Input model) rather than stealing a keyboard grab, which cannot be overridden until the client releases.

Matthew Cudmore (mabcu) wrote :

I deem this is a med-high security issue. I too have noticed the effect several times, whenever I've gotten up from my workstation while a menu (in any application, for me) was open: I returned a while later to find the screen blank as expected, since I also set "blank screen" as my screensaver with "lock screen when screensaver is active" enabled.

However, when I returned to find the blank screen, and I wiggled the mouse, the screen would return to where I left off, with the menu still open. I could then click any of the open menu options, after which the screen would lock, and I would be asked to re-enter my password. If someone else sat at my workstation, they could see what was on my screen before I was distracted, and they could choose a menu option.

Of course, it would be careless of me to leave my workstation without locking it first, given any security concern about someone sitting there while I was gone. Nonetheless, sometimes a sudden distraction or emergency can coax one away from the computer before the thought of locking the desktop even occurs to mind.

Sam Brightman (sambrightman) wrote :

papukaija, did you read my comment in the Redhat bug? It should have been re-titled and was only closed due to distro EOL (despite still existing in the following releases... *sigh*). That bug states that it is a problem with the way gnome-screensaver grabs the keyboard in general, and that clients should not need modification. Probably both bugs should be more general: it is not exclusive to menus being open or VNC.

papukaija (papukaija) wrote :

@Sam: I read your comment from the Redhat bug report. There's nothing I can do for that report since I don't even have (and I'm not willing to have) a username to their bug tracker. Anyway, I tested this in Unity (Maverick UNE) and it didn't work but even the manual screen locking with Ctrl+Alt+L does not work reliably.

Just confirmed that this bug is still present on Gnome 3 (PPA for Ubuntu Natty).

Guys, this is a serious security issue!

Benjamin (benjamin-schaefer) wrote :

This bug is still present in Natty. I discovered it some days ago with an open indicator menu. Didn't know that it had so big a backstory. But now I understand that this is a more general problem.

tags: added: natty

This bug still goes unresolved after 5 1/2 years. Sad.

Josh Leverette (coder543) wrote :

Sad does not even begin to describe it.

Josh Leverette (coder543) wrote :

Notice how many duplicate bugs there are. Yeah... If Canonical were to have one goal for v. 12.04............. fixing what is perhaps the oldest legitimate bug in all of Ubuntu should be priority #1, especially since this is a security flaw.

Marc Deslauriers (mdeslaur) wrote :

This is a design flaw in GTK. This needs to be fixed upstream.

Josh Leverette (coder543) wrote :

Critical bugs have always been solved in a fix first, push fix upstream later approach. This is a critical bug. Companies could unwillingly give up critical data because a screen didn't lock.

I agree with Josh 110%.

Kernel bugs are fixed and pushed upstream by Canonical folks. Why not GTK
bugs / issues? How about security issues for that matter? Waiting 5 1/2
years for a security fix is pretty sad regardless of whos fault it is or
who maintains the code. As a customer of Canonical, I don't care who
maintains the code -- I put the bug into Canonical's bug system, so I
expect someone from Canonical to follow through on it. Simple as that.

On Sun, Dec 4, 2011 at 12:57 PM, Josh Leverette <email address hidden>wrote:

> Critical bugs have always been solved in a fix first, push fix upstream
> later approach. This is a critical bug. Companies could unwillingly give
> up critical data because a screen didn't lock.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (597521).
> https://bugs.launchpad.net/bugs/49579
>
> Title:
> screen doesn't lock when panel menu is open
>
> Status in GNOME Screensaver:
> Confirmed
> Status in “gnome-screensaver” package in Ubuntu:
> Triaged
>
> Bug description:
> Binary package hint: gnome-screensaver
>
> I'm running a fresh install of Dapper with screensaver set to 'blank
> screen', and 'lock screen when screensaver is active' enabled.
>
> If a panel menu (e.g. Applications) is open and the machine is left
> idle, the screen fails to lock. It fades out after the time period as
> expected, but the desktop reappears after a few seconds.
>
> Ben (comments / criticism welcome, this is my first bug report)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
>

This is a limitation in how X handles keyboard grabbing. Essentially, when GTK opens a menu, it needs to grab keyboard and mouse. When that happens, gnome-screensaver cannot exclusively grab the keyboard.

There are two ways to fix this: 1- Redesign how X handles keyboard grabbing, and probably break compatibility with every single X application. 2- Put a hack into GTK to make menus close themselves after an inactivity timeout.

Of course, just fixing the issue in GTK will not fix the issue in other applications that grab the keyboard, such as rdesktop or vnc.

We have plans to move screen locking into LightDM. Once that is done, the screen will lock with a VT switch, which will work around this issue. Also, hopefully Wayland will have a better solution for keyboard grabs.

This isn't a simple fix, the whole system needs to be redesigned to solve this problem. This is why it's not fixed yet.

Josh Leverette (coder543) wrote :

Not a simple fix? Perhaps not, but it's not 5.5 years of complex either. And you listed two solutions, neither of which were good.

Solution: When screen lock seeks to activate, it emits a signal which overrides the mouse and keyboard grabs from all other processes while the screen is locked. Then when the user inputs during the unlock process, the screen lock receives all input. After successfully unlocking, the system 'pops' the screen lock grabs off of a stack and returns the grabs into the previous application. That previous application would see nothing awry, as it would have received no input during the duration, but it would not have received any errors either. This might require modification of the way the x server handles mouse and keyboard grabs, but if the 'hack' were to only allow grab stacking for the screen lock, it shouldn't break compatibility with anything. Simple enough, even if the implementation would require effort.

As far as the wayland and LightDM things go, i dunno. A VT switch? like switching virtual terminals? So.... to hack that machine, I'd need only do ctrl-alt-F7? that seems secure enough. And Wayland will not be ready for 12.04 if I recall correctly, so that's a nonsolution. Businesses need this security, not end users. Businesses use LTS, not regular releases. I hate to be so blunt, but your solution is to wait several more years, and frankly, I'm pretty sure that isn't even remotely an acceptable solution to *anyone* who has been patiently waiting on this to be fixed for 6 years now, especially not business users. Find a better way, or *they* will find Windows, if this is the way security bugs are treated.

Is this bug still relevant?

I just tested this, and xscreensaver successfully locks even with a menu active.

x11-base/xorg-x11-7.4-r1 running x11-wm/openbox-3.5.0-r1 (Gentoo).

Can we close this bug?

Danillo (danillo) wrote :

This bug is still present in Ubuntu 12.04.

papukaija (papukaija) on 2012-05-25
tags: added: precise
dronus (paul-geisler) wrote :

Please raise the importance level as this IS a security issue that creates situations where others can gain access to the computer in situations the owner feels save.

obadz (obadz) wrote :

Agreed that this is a massive security flaw.

Changed in oem-priority:
importance: Undecided → Medium
Changed in oem-priority:
importance: Medium → High
tags: added: rls-q-incoming
Changed in oem-priority:
assignee: nobody → James M. Leddy (jm-leddy)
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-screensaver (Ubuntu Precise):
status: New → Confirmed
Changed in oem-priority:
status: New → Fix Released
Changed in oem-priority:
status: Fix Released → Won't Fix
tags: added: rls-q-notfixing
removed: rls-q-incoming
dronus (paul-geisler) wrote :

This gets more and more important by today, as most users doesn't shutdown their system but use standby. I expect my notebook to be locked if I close the lid. More and more everyday devices like phones and pads trains that expectation and establish screen locks as a tight security feature. So something should be done instantly, even if it is a short living hack that will be overcome by a better design elsewhere.

summary: - screen doesn't lock when panel menu is open
+ screen doesn't lock when some menu is open

I'm still on this boat. It makes the security of Linux into a veritable
laughing stock.
On Oct 8, 2012 5:45 PM, "dronus" <email address hidden> wrote:

> This gets more and more important by today, as most users doesn't
> shutdown their system but use standby. I expect my notebook to be locked
> if I close the lid. More and more everyday devices like phones and pads
> trains that expectation and establish screen locks as a tight security
> feature. So something should be done instantly, even if it is a short
> living hack that will be overcome by a better design elsewhere.
>
> ** Summary changed:
>
> - screen doesn't lock when panel menu is open
> + screen doesn't lock when some menu is open
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (827068).
> https://bugs.launchpad.net/bugs/49579
>
> Title:
> screen doesn't lock when some menu is open
>
> Status in GNOME Screensaver:
> Confirmed
> Status in OEM Priority Project:
> Won't Fix
> Status in OEM Priority Project precise series:
> Won't Fix
> Status in “gnome-screensaver” package in Ubuntu:
> Triaged
> Status in “gnome-screensaver” source package in Precise:
> Confirmed
>
> Bug description:
> Binary package hint: gnome-screensaver
>
> I'm running a fresh install of Dapper with screensaver set to 'blank
> screen', and 'lock screen when screensaver is active' enabled.
>
> If a panel menu (e.g. Applications) is open and the machine is left
> idle, the screen fails to lock. It fades out after the time period as
> expected, but the desktop reappears after a few seconds.
>
> Ben (comments / criticism welcome, this is my first bug report)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
>

Probably we could workaround this problem in unity-panel service, by closing a menu when a such request has been done by UPower, however this would not fix the problems with other application menus.

closing a leak does not always mean inserting a plug, sometimes it just
means lessening the leak to a trickle, one that you can afford to pay for.
In this case, a trickle will do for now.

On Tue, Oct 9, 2012 at 9:07 AM, Marco Trevisan (Treviño) <mail@3v1n0.net>wrote:

> Probably we could workaround this problem in unity-panel service, by
> closing a menu when a such request has been done by UPower, however this
> would not fix the problems with other application menus.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (827068).
> https://bugs.launchpad.net/bugs/49579
>
> Title:
> screen doesn't lock when some menu is open
>
> Status in GNOME Screensaver:
> Confirmed
> Status in OEM Priority Project:
> Won't Fix
> Status in OEM Priority Project precise series:
> Won't Fix
> Status in “gnome-screensaver” package in Ubuntu:
> Triaged
> Status in “gnome-screensaver” source package in Precise:
> Confirmed
>
> Bug description:
> Binary package hint: gnome-screensaver
>
> I'm running a fresh install of Dapper with screensaver set to 'blank
> screen', and 'lock screen when screensaver is active' enabled.
>
> If a panel menu (e.g. Applications) is open and the machine is left
> idle, the screen fails to lock. It fades out after the time period as
> expected, but the desktop reappears after a few seconds.
>
> Ben (comments / criticism welcome, this is my first bug report)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
>

--
Sincerely,
    Josh

Margarita Manterola (marga-9) wrote :

This problem is also present in KDE, so it's not a bug exclusive to gnome-screensaver. As was said before, this is a problem with the way X was designed, and the solutions imply either re-designing X (I doubt there are many people up to such a task) or working around it.

For suspend/hibernate there's the inhibitor locks design doc from Freedesktop, that could allow adding some hooks and forcing pop-up windows to close just before suspending: http://www.freedesktop.org/wiki/Software/systemd/inhibit

It's a different story when trying to manually lock (ctrl-alt-l), since the keyboard is grabbed by the pop-up, no application receives the lock combination and no application can then act appropriately.

In any case it's quite a hard bug to fix, that requires a well thought solution, not a quick hack to fix it.

Will Biscuits (friends-n) wrote :

I'm also experiencing this problem with 12.10. I'm amazed this security hole has been present for 6 1/2 years!

AJenbo (ajenbo) wrote :

It's an inherent issue with the X11 (X.org) design. It has been looked into by a few big developers but solving it is lose to imposible. The solution will be switching to Wayland instead of X.org, somthing that likly will happen in the not to fare away future.

Do you have a pointer to an explanation of this “inherent issue” and why it’s impossible to solve?

What I don’t understand, in particular, is _why_ GTK menus need to grab the mouse and keyboard in the first place. (But if this is an absolute requirement, surely the GTK developers can work with the X developers to come up with a new type of grab that’s cancelable by global shortcut keys and by the screensaver.)

Changed in xorg-server (Debian):
status: Unknown → Confirmed
Changed in xorg-server:
importance: Unknown → Wishlist
status: Unknown → Confirmed
dino99 (9d9) on 2013-05-29
tags: removed: maverick natty qa-jaunty-desktop
manny (estelar57) wrote :

@Anders Kaseorg

you can see the explanation (and more) on this article:

"The Wayland Situation: Facts About X vs. Wayland".

http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1

HerbCSO (herb-earthling) wrote :

@manny - thanks for posting that article, clarifies a lot of things. Based on the explanations there my recommendation would be to close this bug as won't fix since X11 basically makes it ridiculously hard if not downright iimpossible to address this.

manny (estelar57) wrote :

@HerbCSO

Actually I think they might be working on a fix to this indirectly with Mir, just like wayland is trying to do.

So maybe this bug (or a new bug) should get attached to Mir so they don't forget to test it.

Tony Whelan (tony-whelan) wrote :

I don't have a problem with manually locking the screen, especially as I have worked in secure Defence facilities where that is standard pracrtice.

But I do have a problem with a software interface that falsely claims to provide a facility which in fact doesn't work correctly if at all.

To eliminate the immediate problem, distros could get rid of the broken "Lock" setting from the settings menu, and instead just add a notice that CTRL-ALT-L (or whatever) will lock the screen.

The security issue is not that there isn't an effective automatic lock, but that the software creates a false and misleading impression that such a facility exists. That part of the problem could surely be fixed easily by changing the setting dialog box as suggested.

My programming days are long over (anyone remember assembly language?), and I don't know what is involved in removing the "Lock" setting from the Screensaver/Lock dialog box. If I did know, I'd do it myself.

Tony -- exactly! Perfect analysis. Its a false sense of security which
should be abolished or rectified.

--
Kristian Erik Hermansen
https://www.linkedin.com/in/kristianhermansen
https://profiles.google.com/kristian.hermansen
On Nov 4, 2013 5:30 PM, "Tony" <email address hidden> wrote:

> I don't have a problem with manually locking the screen, especially as I
> have worked in secure Defence facilities where that is standard
> pracrtice.
>
> But I do have a problem with a software interface that falsely claims to
> provide a facility which in fact doesn't work correctly if at all.
>
> To eliminate the immediate problem, distros could get rid of the broken
> "Lock" setting from the settings menu, and instead just add a notice
> that CTRL-ALT-L (or whatever) will lock the screen.
>
> The security issue is not that there isn't an effective automatic lock,
> but that the software creates a false and misleading impression that
> such a facility exists. That part of the problem could surely be fixed
> easily by changing the setting dialog box as suggested.
>
> My programming days are long over (anyone remember assembly language?),
> and I don't know what is involved in removing the "Lock" setting from
> the Screensaver/Lock dialog box. If I did know, I'd do it myself.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1226854).
> https://bugs.launchpad.net/bugs/49579
>
> Title:
> screen doesn't lock when some menu is open
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
>

encompass (encompass) wrote :

I totally disagree.
The computer should lock automatically when idle. Instead of solving the
problem you want to get rid of the feature.
There are times when people are distracted and walk away from the
computer. If someone wanted to be malicious this would be their
opportunity. Just do a little "Kevin Mitnik" and your in.

On Tue, Nov 5, 2013 at 4:08 AM, Kristian Erik Hermansen <
<email address hidden>> wrote:

> Tony -- exactly! Perfect analysis. Its a false sense of security which
> should be abolished or rectified.
>
> --
> Kristian Erik Hermansen
> https://www.linkedin.com/in/kristianhermansen
> https://profiles.google.com/kristian.hermansen
> On Nov 4, 2013 5:30 PM, "Tony" <email address hidden> wrote:
>
> > I don't have a problem with manually locking the screen, especially as I
> > have worked in secure Defence facilities where that is standard
> > pracrtice.
> >
> > But I do have a problem with a software interface that falsely claims to
> > provide a facility which in fact doesn't work correctly if at all.
> >
> > To eliminate the immediate problem, distros could get rid of the broken
> > "Lock" setting from the settings menu, and instead just add a notice
> > that CTRL-ALT-L (or whatever) will lock the screen.
> >
> > The security issue is not that there isn't an effective automatic lock,
> > but that the software creates a false and misleading impression that
> > such a facility exists. That part of the problem could surely be fixed
> > easily by changing the setting dialog box as suggested.
> >
> > My programming days are long over (anyone remember assembly language?),
> > and I don't know what is involved in removing the "Lock" setting from
> > the Screensaver/Lock dialog box. If I did know, I'd do it myself.
> >
> > --
> > You received this bug notification because you are subscribed to a
> > duplicate bug report (1226854).
> > https://bugs.launchpad.net/bugs/49579
> >
> > Title:
> > screen doesn't lock when some menu is open
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (139405).
> https://bugs.launchpad.net/bugs/49579
>
> Title:
> screen doesn't lock when some menu is open
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
>

Download full text (3.2 KiB)

Yes but that idle lock feature doesn't work and cannot be trusted. It would
be like saying trust SSL but its using a NULL cipher...

--
Kristian Erik Hermansen
https://www.linkedin.com/in/kristianhermansen
https://profiles.google.com/kristian.hermansen
On Nov 4, 2013 8:55 PM, "encompass" <email address hidden> wrote:

> I totally disagree.
> The computer should lock automatically when idle. Instead of solving the
> problem you want to get rid of the feature.
> There are times when people are distracted and walk away from the
> computer. If someone wanted to be malicious this would be their
> opportunity. Just do a little "Kevin Mitnik" and your in.
>
>
> On Tue, Nov 5, 2013 at 4:08 AM, Kristian Erik Hermansen <
> <email address hidden>> wrote:
>
> > Tony -- exactly! Perfect analysis. Its a false sense of security which
> > should be abolished or rectified.
> >
> > --
> > Kristian Erik Hermansen
> > https://www.linkedin.com/in/kristianhermansen
> > https://profiles.google.com/kristian.hermansen
> > On Nov 4, 2013 5:30 PM, "Tony" <email address hidden> wrote:
> >
> > > I don't have a problem with manually locking the screen, especially as
> I
> > > have worked in secure Defence facilities where that is standard
> > > pracrtice.
> > >
> > > But I do have a problem with a software interface that falsely claims
> to
> > > provide a facility which in fact doesn't work correctly if at all.
> > >
> > > To eliminate the immediate problem, distros could get rid of the broken
> > > "Lock" setting from the settings menu, and instead just add a notice
> > > that CTRL-ALT-L (or whatever) will lock the screen.
> > >
> > > The security issue is not that there isn't an effective automatic lock,
> > > but that the software creates a false and misleading impression that
> > > such a facility exists. That part of the problem could surely be fixed
> > > easily by changing the setting dialog box as suggested.
> > >
> > > My programming days are long over (anyone remember assembly language?),
> > > and I don't know what is involved in removing the "Lock" setting from
> > > the Screensaver/Lock dialog box. If I did know, I'd do it myself.
> > >
> > > --
> > > You received this bug notification because you are subscribed to a
> > > duplicate bug report (1226854).
> > > https://bugs.launchpad.net/bugs/49579
> > >
> > > Title:
> > > screen doesn't lock when some menu is open
> > >
> > > To manage notifications about this bug go to:
> > > https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
> > >
> >
> > --
> > You received this bug notification because you are subscribed to a
> > duplicate bug report (139405).
> > https://bugs.launchpad.net/bugs/49579
> >
> > Title:
> > screen doesn't lock when some menu is open
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1226854).
> https://bugs.launchpad.net/bugs/49579
>
> Title:
> screen doesn't lock when some menu is open
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gnome-scree...

Read more...

encompass (encompass) wrote :
Download full text (3.9 KiB)

So are you proposing we get rid of the autolock functionality because we
can't solve this bug? Or is there some other solution your providing here?

On Tue, Nov 5, 2013 at 6:58 AM, Kristian Erik Hermansen <
<email address hidden>> wrote:

> Yes but that idle lock feature doesn't work and cannot be trusted. It would
> be like saying trust SSL but its using a NULL cipher...
>
> --
> Kristian Erik Hermansen
> https://www.linkedin.com/in/kristianhermansen
> https://profiles.google.com/kristian.hermansen
> On Nov 4, 2013 8:55 PM, "encompass" <email address hidden> wrote:
>
> > I totally disagree.
> > The computer should lock automatically when idle. Instead of solving the
> > problem you want to get rid of the feature.
> > There are times when people are distracted and walk away from the
> > computer. If someone wanted to be malicious this would be their
> > opportunity. Just do a little "Kevin Mitnik" and your in.
> >
> >
> > On Tue, Nov 5, 2013 at 4:08 AM, Kristian Erik Hermansen <
> > <email address hidden>> wrote:
> >
> > > Tony -- exactly! Perfect analysis. Its a false sense of security which
> > > should be abolished or rectified.
> > >
> > > --
> > > Kristian Erik Hermansen
> > > https://www.linkedin.com/in/kristianhermansen
> > > https://profiles.google.com/kristian.hermansen
> > > On Nov 4, 2013 5:30 PM, "Tony" <email address hidden> wrote:
> > >
> > > > I don't have a problem with manually locking the screen, especially
> as
> > I
> > > > have worked in secure Defence facilities where that is standard
> > > > pracrtice.
> > > >
> > > > But I do have a problem with a software interface that falsely claims
> > to
> > > > provide a facility which in fact doesn't work correctly if at all.
> > > >
> > > > To eliminate the immediate problem, distros could get rid of the
> broken
> > > > "Lock" setting from the settings menu, and instead just add a notice
> > > > that CTRL-ALT-L (or whatever) will lock the screen.
> > > >
> > > > The security issue is not that there isn't an effective automatic
> lock,
> > > > but that the software creates a false and misleading impression that
> > > > such a facility exists. That part of the problem could surely be
> fixed
> > > > easily by changing the setting dialog box as suggested.
> > > >
> > > > My programming days are long over (anyone remember assembly
> language?),
> > > > and I don't know what is involved in removing the "Lock" setting from
> > > > the Screensaver/Lock dialog box. If I did know, I'd do it myself.
> > > >
> > > > --
> > > > You received this bug notification because you are subscribed to a
> > > > duplicate bug report (1226854).
> > > > https://bugs.launchpad.net/bugs/49579
> > > >
> > > > Title:
> > > > screen doesn't lock when some menu is open
> > > >
> > > > To manage notifications about this bug go to:
> > > >
> https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
> > > >
> > >
> > > --
> > > You received this bug notification because you are subscribed to a
> > > duplicate bug report (139405).
> > > https://bugs.launchpad.net/bugs/49579
> > >
> > > Title:
> > > screen doesn't lock when some menu is open
> > >
> > > To manage notifications...

Read more...

Download full text (4.7 KiB)

Yes. Remove it since it is a decade long bug.

--
Kristian Erik Hermansen
https://www.linkedin.com/in/kristianhermansen
https://profiles.google.com/kristian.hermansen
On Nov 4, 2013 9:20 PM, "encompass" <email address hidden> wrote:

> So are you proposing we get rid of the autolock functionality because we
> can't solve this bug? Or is there some other solution your providing here?
>
>
> On Tue, Nov 5, 2013 at 6:58 AM, Kristian Erik Hermansen <
> <email address hidden>> wrote:
>
> > Yes but that idle lock feature doesn't work and cannot be trusted. It
> would
> > be like saying trust SSL but its using a NULL cipher...
> >
> > --
> > Kristian Erik Hermansen
> > https://www.linkedin.com/in/kristianhermansen
> > https://profiles.google.com/kristian.hermansen
> > On Nov 4, 2013 8:55 PM, "encompass" <email address hidden> wrote:
> >
> > > I totally disagree.
> > > The computer should lock automatically when idle. Instead of solving
> the
> > > problem you want to get rid of the feature.
> > > There are times when people are distracted and walk away from the
> > > computer. If someone wanted to be malicious this would be their
> > > opportunity. Just do a little "Kevin Mitnik" and your in.
> > >
> > >
> > > On Tue, Nov 5, 2013 at 4:08 AM, Kristian Erik Hermansen <
> > > <email address hidden>> wrote:
> > >
> > > > Tony -- exactly! Perfect analysis. Its a false sense of security
> which
> > > > should be abolished or rectified.
> > > >
> > > > --
> > > > Kristian Erik Hermansen
> > > > https://www.linkedin.com/in/kristianhermansen
> > > > https://profiles.google.com/kristian.hermansen
> > > > On Nov 4, 2013 5:30 PM, "Tony" <email address hidden> wrote:
> > > >
> > > > > I don't have a problem with manually locking the screen, especially
> > as
> > > I
> > > > > have worked in secure Defence facilities where that is standard
> > > > > pracrtice.
> > > > >
> > > > > But I do have a problem with a software interface that falsely
> claims
> > > to
> > > > > provide a facility which in fact doesn't work correctly if at all.
> > > > >
> > > > > To eliminate the immediate problem, distros could get rid of the
> > broken
> > > > > "Lock" setting from the settings menu, and instead just add a
> notice
> > > > > that CTRL-ALT-L (or whatever) will lock the screen.
> > > > >
> > > > > The security issue is not that there isn't an effective automatic
> > lock,
> > > > > but that the software creates a false and misleading impression
> that
> > > > > such a facility exists. That part of the problem could surely be
> > fixed
> > > > > easily by changing the setting dialog box as suggested.
> > > > >
> > > > > My programming days are long over (anyone remember assembly
> > language?),
> > > > > and I don't know what is involved in removing the "Lock" setting
> from
> > > > > the Screensaver/Lock dialog box. If I did know, I'd do it myself.
> > > > >
> > > > > --
> > > > > You received this bug notification because you are subscribed to a
> > > > > duplicate bug report (1226854).
> > > > > https://bugs.launchpad.net/bugs/49579
> > > > >
> > > > > Title:
> > > > > screen doesn't lock when some menu is open
> > > > >
> > > > > To manage notificati...

Read more...

Tony Whelan (tony-whelan) wrote :

Encompass wrote: "The computer should lock automatically when idle. Instead of solving the problem you want to get rid of the feature."

But the feature only works some of the time, and the thread here makes it clear it isn't going to be fixed while the system uses X.

A security feature that only works some of the time is like a set of brakes that only works some of the time ... damn dangerous.

Remove it until we have something that can be trusted.

Daniel van Vugt (vanvugt) wrote :

Initially I was tempted to say we can't fix it because popup menus own ("grab") the keyboard and that blocks the screensaver from taking ownership of the keyboard. But now I wonder...

Can't the screensaver just force XUngrabKeyboard before trying to grab it? Would that work?

obadz (obadz) wrote :

Either that and even if it doesn't work, can't we get a hack that kills the entire X session in the event the lock is unsuccessful? Or call a user-defined script? Those would be more useful than removing the feature altogether.

Daniel van Vugt (vanvugt) wrote :

Killing the whole login is pointless because you'd be killing that which a locked screen is meant to protect.
Killing just the X session (client) holding the lock is unacceptable because killing a user's apps or shell is worse than the bug itself.

If we can get the screensaver to just XUngrabKeyboard and XUngrabPointer before it attempts to grab them itself, then that would be great. I'm just not sure if X lets you ungrab grabs you didn't create, so it may not work.

@Ctrl-Alt-L is also broken. You need to close menus and other popups first, otherweise the key combination will simply be ignored.

Also, on Multimonitor setups sometimes the second screen still shows its content, despite the lock being activated.

IMHO the only reliable way of locking your Ubuntu computer is logging out (manually).

obadz (obadz) wrote :

> Killing just the X session (client) holding the lock is unacceptable because killing a user's apps or shell is worse than the bug itself.

I wholeheartedly disagree. shutdown the computer altogether would be less bad than granting access when the user expects otherwise..

Keller-scholl (keller-scholl) wrote :

That entirely depends on how much your prioritize security over usefulness.
I would not want that to happen, because I don't have secure things, by and
large. I can completely understand other people disagreeing. Ubuntu isn't
about prioritizing security over all else, I feel. A shutdown is excessive
to avoid people seeing the screen for a few seconds.

On Tue, Nov 5, 2013 at 9:36 AM, Obadz <email address hidden> wrote:

> > Killing just the X session (client) holding the lock is unacceptable
> because killing a user's apps or shell is worse than the bug itself.
>
> I wholeheartedly disagree. shutdown the computer altogether would be
> less bad than granting access when the user expects otherwise..
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1215976).
> https://bugs.launchpad.net/bugs/49579
>
> Title:
> screen doesn't lock when some menu is open
>
> Status in GNOME Screensaver:
> Confirmed
> Status in OEM Priority Project:
> Won't Fix
> Status in OEM Priority Project precise series:
> Won't Fix
> Status in X.Org X server:
> Confirmed
> Status in “gnome-screensaver” package in Ubuntu:
> Triaged
> Status in “gnome-screensaver” source package in Precise:
> Confirmed
> Status in “xorg-server” package in Debian:
> Confirmed
>
> Bug description:
> Binary package hint: gnome-screensaver
>
> I'm running a fresh install of Dapper with screensaver set to 'blank
> screen', and 'lock screen when screensaver is active' enabled.
>
> If a panel menu (e.g. Applications) is open and the machine is left
> idle, the screen fails to lock. It fades out after the time period as
> expected, but the desktop reappears after a few seconds.
>
> Ben (comments / criticism welcome, this is my first bug report)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gnome-screensaver/+bug/49579/+subscriptions
>

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.