After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 311780 - Ability to lock local screen when open remotely
Ability to lock local screen when open remotely
Status: RESOLVED WONTFIX
Product: vino
Classification: Applications
Component: Server
unspecified
Other All
: High enhancement
: ---
Assigned To: Vino Maintainer(s)
Vino Maintainer(s)
: 389649 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-07-27 18:11 UTC by madcap
Modified: 2020-11-12 12:24 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description madcap 2005-07-27 18:11: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.
Comment 1 Jeremy Nickurak 2006-03-29 20:27:49 UTC
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?
Comment 2 Mark McLoughlin 2006-10-23 11:03:34 UTC
Yeah, it would definitely be nice ... not clear how to implement it, though
Comment 3 Jonh Wendell 2006-12-26 10:58:13 UTC
*** Bug 389649 has been marked as a duplicate of this bug. ***
Comment 4 Ray Strode [halfline] 2007-03-28 14:36:09 UTC
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. 
Comment 5 dosboss64 2011-05-10 20:36:26 UTC
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.
Comment 6 André Klapper 2020-11-12 12:24:41 UTC
Vino is not under active development anymore and unmaintained.

Please use gnome-remote-desktop instead.

Closing this report as WONTFIX to reflect reality.