Virtual Machine Viewer prevents screen lock in host machine

[Phill]

If you have a virtual machine open in Virtual Machine Viewer and that has focus, the screen lock on the guest does not activate, even when coming out of standby.

This means that information on the guest desktop remains visible.

The screen lock activates when you click on anything outside of the guest.

The workaround is to close the window before putting the machine into standby, or manually lock the screen. However, this works against the security features that are intended to be automatic and is easily missed.

An aggravating factor is that that this behaviour is not obvious. It is not obvious from the outset and even after having experienced it a few times it is easy to mistake it as a screen-lock malfunction rather than a deliberate feature of the viewer. This means new users will always get caught out and it may take them some time to figure out what is going on and how to avoid it.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: virt-manager 1:1.3.2-3ubuntu1.16.04.1
ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
Uname: Linux 4.4.0-31-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Jul 27 11:09:08 2016
ExecutablePath: /usr/share/virt-manager/virt-manager
InstallationDate: Installed on 2016-06-13 (43 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
InterpreterPath: /usr/bin/python2.7
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: virt-manager
UpgradeStatus: No upgrade log present (probably fresh install)

[Seth Arnold (seth-arnold)]

There's enough reasons why the screenlockers won't work automatically that if you really want your workstation locked when you walk away from it, you need to lock it manually when you leave.

Thanks

[Phill (phill.l)]

Some computers and keyboards come with a standby key/button, laptops usually have a lid-switch. In many cases, pressing the suspend key, or closing the lid, is the manual action that is taken to lock the screen and simultaneously suspend the computer. While I realise that an application might inhibit suspend, there should be no reason why an application should be allowed to inhibit the screen lock of a computer that has been suspended, manually, by lid switch, keyboard or otherwise.

Seth, if you are familiar with other faults with the screen locking process, which is what your comment seems to suggest, then I would encourage you to report them in detail as separate bugs.

Thanks

[Seth Arnold (seth-arnold)]

Phill, see bug #49579 (or bug 49579 in case the # breaks the auto linkification).

Thanks

[Phill (phill.l)]

Cheers for the reference, however, I think that's a different bug because it relates to suspend/screen-saver not kicking in, although the comment section has become a dumping ground for related issues and there is the odd mention of suspend problems.

This bug does not relate to the screen-saver or lock failing to kick in when idle. It relates to the situation where the computer does suspend properly (evidenced by a flashing power button on my hardware), usually from lid-close but also from idling, but wakes from the suspend without the lock screen.

The serious nature of this bug is that, with the computer suspended, there is no what to see that the lock screen has not kicked in. If the computer failed to suspend or as with the other bug the screen-lock didn't kick in, it would be apparent to the user and less of an issue.

I've done a little investigation and found: If the viewer has keyboard capture the problem occurs every time, but you need to suspend with a lid-close or something the viewer doesn't capture. Otherwise, the problem can occur when the view just has focus (or last focus if Suspend is chosen from the power menu), but this is less reliable it may need to be under the mouse pointer at the time of suspend or having the window maximised. In this case I was using a laptop and running the "mini.iso" Ubuntu installer in the VM, just booted to the menu.

[Serge Hallyn (serge-hallyn)]

Here's where I'm happy to be using a custom /etc/acpi based lock trigger (using slock).

I'd have to agree with Phil, this bug seems worse. Having to manually lock my screen and verify that it worked before suspending every time would be unacceptable to me.

[Marc Deslauriers (mdeslaur)]

When an application has a keyboard or mouse lock, the screensaver can't come up because there is no X API to forcibly remove the lock form the application. This is a long-standing design flaw in X, and is the cause of all the fail-to-lock bugs, including all the ones that are duped to bug 49579.