GNOME Bugzilla – Bug 311780
Ability to lock local screen when open remotely
Last modified: 2020-11-12 12:24:41 UTC
It would be nice, as a preference, to be able to have the local screen locked when a remote session is active. This is good for a shared computer environment (e.g. office, lab) where you want to use your desktop remotely without letting everyone see/use your desktop locally when you're not there.
It does seem like a pretty important feature. It wasn't until very recently that I realised that this was a problem, and I had to think pretty hard about whether someone who may have been in the room could have seen confidential or sensitive information. Is there a practical solution to this sort of issue?
Yeah, it would definitely be nice ... not clear how to implement it, though
*** Bug 389649 has been marked as a duplicate of this bug. ***
One way to implement it would be to redirect all windows (except for the screen saver window) off screen using the composite extension and then scraping from the named pixmaps instead of the screen. I guess that would fall over if a compositing manager was already running though. Still, seems pretty hard to implement.
A 6-year-old request for this doesn't make me hopeful that it will be implemented soon... but a suggestion: What about moving the console to another virtual terminal? Like when hitting <CTRL>-<ALT>-F2/F3/F4/etc. from inside X, or <ALT>-F2/F3/F4/etc. from a virtual terminal? If the central focus of the VNC client (or Vino?) stayed on the display that X was running on (by default the user session is on X display :0), then the main console would be shifted to what is essentially a login or blank virtual console screen. A way to do this from the command line is (using xte from the xautomation package in Fedora): /usr/bin/xte "keydown Control_L" "keydown Alt_L" "key F12" "keyup Alt_L" "keyup Control_L" Of course that command leaves the VNC client connection with a static screen, and all STDIN is redirected to the new console, leaving the VNC client stranded. Also if there was a way for Vino to simply create another display in X (:10 for example, running on a new TTY), you could attach the local console to the new X display which would be running the following xinitrc: xsetroot -display :10 -solid blue /path/to/xdummyscript xdummyscript: #!/bin/bash while $myvar -ne 1; do xmessage -display :10 -buttons "Log off user":1,Cancel:2 -center -default Cancel "Another user is using the console. Would you like to log off the user?" myvar=`echo $?` case $myvar in 1) /path/to/log_out_user ;; # confirmation and script to log out VNC user, #+kill :10, and restart the :0 window manager/ #+display manager login *) unset $myvar ;; # loop esac done Of course you could get much more fancy (Zenity, custom dialogs, etc), and the log out option wouldn't be mandatory, this is just a quick mind dump using tools that basically come with Xorg. It (mostly) duplicates what I know of the functionality of win RDP sessions, anyway. If Vino could maintain keyboard and mouse focus on the main X display (:0), then it shouldn't affect the VNC client. Of course detaching Vino from the console might require something like running the :0 display in a VNC server environment, and modifying gdm to act like a VNC client attaching to the session locally. All possible, but complicated (I have run gdm in a TigerVNC server and used it like my workstation that you connect to from anywhere, but it's a pain to set up). This really shouldn't be required though, as X was designed to be network-able anyway. It's just the easiest way I can think of while still using the VNC protocol.
Vino is not under active development anymore and unmaintained. Please use gnome-remote-desktop instead. Closing this report as WONTFIX to reflect reality.