screen doesn't lock when some menu is open

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.

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

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.

This is still an issue in intrepid.

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.

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

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

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.

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?

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

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

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

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

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

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?!

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

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

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.

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.

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.

@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!

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.

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

Sad does not even begin to describe it.

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.

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

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.

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.

This bug is still present in Ubuntu 12.04.

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.

Agreed that this is a massive security flaw.

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

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.

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

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.

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

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

@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

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

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

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
>

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
>

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

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

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

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.

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?

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.

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

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

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
>

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

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

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
>

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.

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

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.

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.

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
>
--

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

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

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

https://wiki.ubuntu.com/Releases

wily.

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

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?

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

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.

Precise is EOL

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.

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

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?

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

Release EOL