Bug 1903090 - Remote desktop sharing does not work when host is locked
Summary: Remote desktop sharing does not work when host is locked
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-remote-desktop
Version: 33
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Søren Sandmann Pedersen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-01 10:14 UTC by Petr Parik
Modified: 2021-01-20 20:15 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Petr Parik 2020-12-01 10:14:27 UTC
Description of problem:

(1) It is not possible to connect via VNC to the host that is locked (i.e., the host shows the lock screen).

(2) Existing VNC connection is terminated the moment the host locks screen.

(3) If the host is unlocked (by **physically** logging in), then it is possible to connect via VNC until (2) happens.

Version-Release number of selected component (if applicable):

server: vino 3.22.0-19.fc33 (Fedora 33, GNOME on X11)
client: vinagre 3.22.0-18.fc31 (Fedora 31, GNOME on X11)

How reproducible:

always

Steps to Reproduce:
1. connect to **unlocked** host
2. wait for host to lock screen (or lock screen manually)
-or-
1. try to connect to **locked** host

Actual results:

VNC client is disconnected and cannot reconnect
-or-
VNC client cannot connect at all

Expected results:

VNC connection is possible to locked host, VNC connection is maintained in case the host locks screen (so the user can log in again)

Additional info:

This problem started after upgrading the host from F31 to F33. Built-in screen sharing worked flawlessly in F31.

VNC server used before upgrade was vino 3.22.0-16.fc31 (Fedora 31, GNOME on X11).

It might be a bug in another component (not in vino).

Comment 1 Jonas Ådahl 2021-01-20 16:57:32 UTC
This is by design, as there is a risk that unlocking remotely could unknowingly present the logged in session to anyone at the physical computer. It can be avoided by running the following two commands in looking glass:

global.backend.get_remote_access_controller().inhibit_remote_access = () => {}
global.backend.get_remote_access_controller().uninhibit_remote_access = () => {}

Comment 2 Petr Parik 2021-01-20 19:51:18 UTC
Well, I am not happy with this change.

Is this solution persistent across reboots? If not, how can I make it run automatically on every reboot (login)?

Thanks.

Comment 3 Jonas Ådahl 2021-01-20 20:00:03 UTC
> Is this solution persistent across reboots? If not, how can I make it run automatically on every reboot (login)?

It is not. To make it persistent, either it needs to be turned into an extension, or it can be placed in a script that is executed on login. Eventually the plan is to make sure that logging in remotely will not enable the screen on the physical computer, but that is not ready yet.

Comment 4 Petr Parik 2021-01-20 20:15:13 UTC
> Eventually the plan is to make sure that logging in remotely will not enable
> the screen on the physical computer, but that is not ready yet.

I am looking forward to that. That's how remote desktop works on Windows.


Note You need to log in before you can comment on or make changes to this bug.