screen doesn't lock when some menu is open

Bug #49579 reported by Ben Scholl
This bug affects 161 people
Affects Status Importance Assigned to Milestone
GNOME Screensaver
Expired
Medium
OEM Priority Project
Won't Fix
High
James M. Leddy
Precise
Won't Fix
High
James M. Leddy
Unity
Triaged
High
Marco Trevisan (Treviño)
7.2
Triaged
High
Marco Trevisan (Treviño)
X.Org X server
Invalid
Wishlist
gnome-screensaver (Ubuntu)
Triaged
High
Unassigned
Precise
Won't Fix
High
Unassigned
Quantal
Won't Fix
Undecided
Unassigned
Wily
Won't Fix
Undecided
Unassigned
Xenial
Triaged
High
Unassigned
gnome-shell (Ubuntu)
Confirmed
Undecided
Unassigned
Precise
Confirmed
Undecided
Unassigned
Quantal
Won't Fix
Undecided
Unassigned
Wily
Won't Fix
Undecided
Unassigned
Xenial
Confirmed
Undecided
Unassigned
unity (Ubuntu)
Triaged
High
Unassigned
Precise
Won't Fix
High
Unassigned
Quantal
Won't Fix
Undecided
Unassigned
Wily
Won't Fix
Undecided
Unassigned
Xenial
Triaged
High
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)

Revision history for this message
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
Revision history for this message
Nikhil Fernandes (njfernandes) wrote :

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

Revision history for this message
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.

Revision history for this message
Martin Schaaf (mascha) wrote :

This is still an issue in intrepid.

Changed in gnome-screensaver:
status: Confirmed → Triaged
Revision history for this message
In , Noël Köthe (noel) wrote :

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.

Revision history for this message
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

Revision history for this message
Paolo Montrasio (paolo-paolomontrasio) wrote :

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.

Revision history for this message
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...

Revision history for this message
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
Revision history for this message
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)
Revision history for this message
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
Revision history for this message
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
Revision history for this message
Rafal-maj-it (rafal-maj-it) wrote :

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

Changed in gnome-screensaver:
status: New → Confirmed
Revision history for this message
Lê Kiến Trúc (le-kien-truc) wrote :

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
Revision history for this message
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...

Revision history for this message
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
Revision history for this message
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?!

Revision history for this message
papukaija (papukaija) wrote :

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

Revision history for this message
papukaija (papukaija) wrote :

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

Revision history for this message
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
Revision history for this message
In , Bugs-freedesktop (bugs-freedesktop) wrote :

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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Andreas Schildbach (schildbach) wrote :

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

Guys, this is a serious security issue!

Revision history for this message
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
Revision history for this message
Brad.Turnbough (brad-turnbough) wrote :

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

Revision history for this message
Josh Leverette (coder543) wrote :

Sad does not even begin to describe it.

Revision history for this message
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.

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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

Revision history for this message
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.

Revision history for this message
Brad.Turnbough (brad-turnbough) wrote : Re: [Bug 49579] Re: screen doesn't lock when panel menu is open

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
>

Revision history for this message
Marc Deslauriers (mdeslaur) wrote : Re: screen doesn't lock when panel menu is open

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.

Revision history for this message
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.

Revision history for this message
In , Freedesktop-6 (freedesktop-6) wrote :

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?

Revision history for this message
Danillo (danillo) wrote :

This bug is still present in Ubuntu 12.04.

papukaija (papukaija)
tags: added: precise
Revision history for this message
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.

Revision history for this message
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)
Revision history for this message
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
Revision history for this message
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
Revision history for this message
Josh Leverette (coder543) wrote : Re: [Bug 49579] Re: screen doesn't lock when panel 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
>

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) 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.

Revision history for this message
Josh Leverette (coder543) wrote : Re: [Bug 49579] Re: screen doesn't lock when some menu is open

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

Revision history for this message
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.

Revision history for this message
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!

Revision history for this message
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.

Revision history for this message
Anders Kaseorg (andersk) wrote :

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)
tags: removed: maverick natty qa-jaunty-desktop
Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote : Re: [Bug 49579] Re: screen doesn't lock when some menu is open

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
>

Revision history for this message
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
>

Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote :
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...

Revision history for this message
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...

Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote :
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...

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Andreas Schildbach (schildbach) wrote :

@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).

Revision history for this message
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..

Revision history for this message
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
>

Changed in unity:
importance: Undecided → High
status: New → Triaged
milestone: none → 7.3.0
tags: added: lockscreen
Changed in unity:
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
Stephen M. Webb (bregma)
Changed in unity:
milestone: 7.3.0 → 7.3.1
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu Precise):
status: New → Confirmed
Changed in gnome-screensaver:
status: Confirmed → Expired
Revision history for this message
Gael Lafond (gaellafond) wrote :

This bug also occur with contextual menu. Right click anywhere and wait. The screen goes black after a while. Move the mouse to activate the screen. The screen is NOT lock. Strangely, the screen lock immediately after the menu disappear (left click anywhere outside the menu).

Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote :

Gael -- Correct. Makes you wonder if this is ever going to be fixed since
it is well known for many years...

On Sun, Nov 9, 2014, 7:30 PM Gael Lafond <email address hidden> wrote:

> This bug also occur with contextual menu. Right click anywhere and wait.
> The screen goes black after a while. Move the mouse to activate the
> screen. The screen is NOT lock. Strangely, the screen lock immediately
> after the menu disappear (left click anywhere outside the menu).
>
> --
> 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
>

Revision history for this message
AJenbo (ajenbo) wrote :

The only way to fix it is to switch away from X.org, Mir is in the works so you could say that they are working on fixing it.

Stephen M. Webb (bregma)
Changed in unity:
milestone: 7.3.1 → 7.3.2
Stephen M. Webb (bregma)
Changed in unity:
milestone: 7.3.2 → 7.3.3
Revision history for this message
madbiologist (me-again) wrote :

Ctrl-Alt-L works here when menus are open. The idle timeout also blanks and locks the screen when menus are open and pressing a key unblanks the screen to reveal the lockscreen which cannot be bypassed by further keypresses or mouseclicks.

Ubuntu 14.04.2 LTS.
unity 7.2.5+14.04.20150603-0ubuntu1

Revision history for this message
Seth Johnson (sethj) wrote :

As part of the big bug review for 16.04 LTS I have tested this on 15.10 and the bug is still there. I reproduced by opening the context menu on the desktop.

tags: added: ubuntu-bugscrub-triaged
tags: added: desktop-bugscrub-triaged
removed: ubuntu-bugscrub-triaged
Revision history for this message
Mateusz Stachowski (stachowski-mateusz) wrote :

Yes screen gets locked when menus are open since a couple of Unity releases.

But right click context menus are a different story. For example when I have right click menu opened in Nautilus the screen goes blank but when I move the cursor I see the whole screen and then only after clicking somwhere screen gets locked. So you can't interact with programs but you can see everything.

Also with right click menu in Opera the screen never gets locked. But right click menu opened in FireFox, Spotify, Ubuntu Web Browser gets screen locked at the same time it blanks.

Revision history for this message
xtsbdu3reyrbrmroezob (xtsbdu3reyrbrmroezob) wrote :

Surely this is an NSA backdoor :)

On Wed, Sep 16, 2015 at 1:26 PM Mateusz Stachowski <email address hidden>
wrote:

> Yes screen gets locked when menus are open since a couple of Unity
> releases.
>
> But right click context menus are a different story. For example when I
> have right click menu opened in Nautilus the screen goes blank but when
> I move the cursor I see the whole screen and then only after clicking
> somwhere screen gets locked. So you can't interact with programs but you
> can see everything.
>
> Also with right click menu in Opera the screen never gets locked. But
> right click menu opened in FireFox, Spotify, Ubuntu Web Browser gets
> screen locked at the same time it blanks.
>
> --
> 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
>
--

Revision history for this message
madbiologist (me-again) wrote :

Thanks Mateusz. The only right-click context menu I tested was the Firefox one. I guess Firefox doesn't use GTK/GTK+.

I can confirm the behaviour you described with the right-click context menu in Nautilus. Excellent description too, by the way.

Ubuntu 14.04.2 LTS.
unity 7.2.5+14.04.20150603-0ubuntu1

Revision history for this message
José Vidal (josevidal) wrote :

As part of the big bug review for 16.04 LTS I have tested this on 15.10 and the bug is still there.

Revision history for this message
Sasa Paporovic (melchiaros) wrote :

Than Jose it is suggested to add the tag for 15.10 to the report. Adding regarding to

https://wiki.ubuntu.com/Releases

wily.

tags: added: wily
Changed in gnome-screensaver (Ubuntu Precise):
importance: Undecided → High
Changed in unity (Ubuntu):
importance: Undecided → High
Changed in unity (Ubuntu Precise):
importance: Undecided → High
Changed in gnome-screensaver (Ubuntu):
importance: Low → High
Changed in gnome-screensaver (Ubuntu Precise):
status: Confirmed → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
Changed in unity (Ubuntu Precise):
status: Confirmed → Triaged
tags: added: rls-w-incoming
Changed in unity:
milestone: 7.3.3 → 7.4.0
tags: added: rls-x-incoming
removed: rls-w-incoming
Will Cooke (willcooke)
tags: added: u7-trello-import
Changed in unity (Ubuntu):
assignee: Marco Trevisan (Treviño) (3v1n0) → Rahul (rahulshantagiri9999)
Will Cooke (willcooke)
tags: removed: rls-x-incoming
Changed in unity (Ubuntu Xenial):
assignee: Rahul (rahulshantagiri9999) → nobody
Changed in gnome-screensaver (Ubuntu Precise):
assignee: nobody → Rahul (rahulshantagiri9999)
Changed in unity (Ubuntu Xenial):
milestone: none → ubuntu-16.04
Will Cooke (willcooke)
tags: removed: u7-trello-import
tags: added: unity-backlog
Revision history for this message
Robert Hönig (indielives010) wrote :

So under xenial, I can't reproduce the bug, it seems to be fixed.

Changed in gnome-screensaver (Ubuntu Xenial):
status: Triaged → Fix Released
papukaija (papukaija)
Changed in gnome-screensaver (Ubuntu Precise):
assignee: Rahul (rahulshantagiri9999) → nobody
Mathew Hodson (mhodson)
Changed in unity (Ubuntu):
milestone: ubuntu-16.04 → none
Changed in unity (Ubuntu Xenial):
milestone: ubuntu-16.04 → none
Changed in gnome-screensaver (Ubuntu):
status: Fix Released → Triaged
Changed in gnome-screensaver (Ubuntu Xenial):
status: Fix Released → Triaged
Revision history for this message
Eli (eliterdaboss) wrote :

So, you can't redesign it to allow two programs to grab the keyboard and mouse?

I would suggest that each program, by default, will have the complete attention of the mouse and keyboard. If a program calls a function, method on an API (I don't work in your world, sorry. Bear with me), it will flip it from default and allow two programs/packages at once to have the keyboard and mouse?

Revision history for this message
Eli (eliterdaboss) wrote :

In 16.04, it is still an issue (for me at least)

Revision history for this message
Roman (rmaksimov) wrote :

It is still present in Ubuntu 16.04.

All as described here: https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/1124282
"If the Windows window is on focus and i am inactive, then my screen is locked after a certain amount of time and should normally ask for my password. But it only does so if a change the focus to a window other than my virtual machine."
but it will be locked after a certain amount of time then and only then you click on some area of the host (it's not enough just to move the cursor outside of vm). Otherwise, you will be able to work inside the vm.

Moreover, in this case (in conjuction with VirtualBox 5.1.28 r117968) it is possible to bypass the lock screen and unlock the host without needing to enter a password. All you need is just double click inside the vm window (lock screen will blink and disappear). After that you will be able to interact with the host.

Steps to reproduce:
1. System Settings > Brightness and Lock.
2. Set "Turn screen off when inactive for" to 1 minute.
3. Turn on "Lock", set "Lock screen after" to "Screen turns off", check "Require my password when waking from suspend" checkbox.
3. Focus to the virtual machine window.
4. Wait 61 seconds.
5. Double click inside the vm.

Revision history for this message
In , Ajax-a (ajax-a) wrote :

*** This bug has been marked as a duplicate of bug 4286 ***

Changed in xorg-server:
status: Confirmed → Invalid
Revision history for this message
Jeff Lane  (bladernr) wrote :

Precise is EOL

Changed in gnome-screensaver (Ubuntu Precise):
status: Triaged → Won't Fix
Changed in unity (Ubuntu Precise):
status: Triaged → Won't Fix
Revision history for this message
Nicholas Klopfer-Webber (ottago) wrote :

I can't believe this bug is still open. The report goes back more than 10 years.

Also the duplicate (bug 4286) mentioned above is incorrect, it points an avifile issue.

This is a incredibly high security issue that should be fixed immediately. Not only all the examples mentioned above by meany people, but the more concerning case is when you close the screen on a laptop. Even with lock screen turned on (I'm using the default gnome with Ubuntu) when you open the lid again no password is required. It makes encrypting your disk a bit pointless.

Please look into it.

Revision history for this message
Christian Hubmann (chrishub) wrote :

This bug is still present in Ubuntu 20.10 / Gnome 3.38. This is a huge issue especially in corporate environments.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This bug is currently not assigned to any components of "Ubuntu 20.10 / Gnome 3.38". But we can change that... Do you experience it in both Xorg and Wayland sessions? Or just when app menus are open?

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-shell (Ubuntu Precise):
status: New → Confirmed
Changed in gnome-shell (Ubuntu Xenial):
status: New → Confirmed
Changed in gnome-shell (Ubuntu):
status: New → Confirmed
tags: added: oem-priority
Revision history for this message
Jeff Lane  (bladernr) wrote :

Release EOL

Changed in unity (Ubuntu Quantal):
status: New → Won't Fix
Changed in unity (Ubuntu Wily):
status: New → Won't Fix
Changed in gnome-shell (Ubuntu Wily):
status: New → Won't Fix
Changed in gnome-shell (Ubuntu Quantal):
status: New → Won't Fix
Changed in gnome-screensaver (Ubuntu Wily):
status: New → Won't Fix
Changed in gnome-screensaver (Ubuntu Quantal):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

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