| 2012-10-02 17:34:57 |
aproposnix |
description |
Ubuntu 12.04 (64bit) - latest updates applied
Affects Unity 3D (not tested on 2d)
Issue Summary: When using virtualbox (VB) in fullscreen mode, VB takes control of the screen. This means that even though the Linux host desktop is locked I still am able to function in the guest OS without having to log into the linux host (when the screnesave lock comes on).
The problem I have been faced with over the past few months is that whenever I lock the VB guest (it's windows, so I'm using Alt-L to lock it) it activates the Unity Dashboard in the background. What happens then is that when I come back to my computer I log into windows but the password is actually being written to the Unity Dashboard. I've had it happen already a few times at work where I had people standing around and my password was exposed to them.
Expected behaviour - Virtualbox should have control of the screen until I either minimize the VB or I close it completely. Instead of this, sometimes the host OS is taking over the keyboard in the background.
I'm not really sure whther this is a Unty bug or a virtualbox bug. Any thoughts on how to resolve this (security) issue? |
Ubuntu 12.04 (64bit) - latest updates applied
Affects Unity 3D (not tested on 2d)
Issue Summary: When using virtualbox (VB) in fullscreen mode, VB takes control of the screen. This means that even though the Linux host desktop is locked I still am able to function in the guest OS without having to log into the linux host (when the screnesave lock comes on).
The problem I have been faced with over the past few months is that whenever I lock the VB guest (it's windows, so I'm using Alt-L to lock it) it activates the Unity Dashboard in the background. What happens then is that when I come back to my computer I log into windows but the password is actually being written to the Unity Dashboard. I've had it happen already a few times at work where I had people standing around and my password was exposed to them.
Expected behaviour - Virtualbox should have control of the screen until I either minimize the VB or I close it completely. Instead of this, sometimes the host OS is taking over the keyboard in the background. |
|
