Lock the physical screen when somebody connects doesn’t work as expected

[Lantizia]

Got an e-mail today…

FEATURE REQUEST: Updates to FR09I02610 on 2015-10-01
Supporting the blank screen feature during a remote desktop session
Reason was: Feature is implemented in the NoMachine version 5.0.43.

So I’ve upgraded NoMachine running on my Ubuntu MATE (64-bit) PC to the new 5.0.43 version, made sure to tick the new ‘Lock the physical screen when somebody connects’ option and then connected in to my machine from my Android tablet (still running 4.4.12).

The physical screens do go black with just my cursor showing (that I can still move around) but there are a few glitches…

a) If I click or type on my PC (despite the screen being black) I’m still interacting with the windows behind it, so not secure.
b) If I need to take back control of my PC without tracking down the client that is connected and disconnecting it, I can’t.

To me this looks like a half-finished feature (as you can’t really call this a “Lock” as the checkbox suggests, just blanked), and therefore FR09I02610 shouldn’t be marked as Implemented as it doesn’t do what it was meant to. Otherwise if it is a bug then fair enough.

Thoughts anyone?

Steven

[fra81]

Hi Lantizia,

thank you for this report, we are going to check it in the same environment. The expected behaviour is that user input is blocked. This is certainly a bug, since the tens of Linux distributions we tested it on don’t have this problem.

[fra81]

We did not reproduce this issue in our labs on Ubuntu 12.04 with MATE. Can you tell us your exact Ubuntu version?

Please also send us the output of the ‘xinput’ command run on the server machine.

[Lantizia]

Ubuntu MATE 14.04 LTS from https://ubuntu-mate.org/trusty/

 

stevenm@stevenm-ubuntu:~$ xinput

⎡ Virtual core pointer                    id=2[master pointer  (3)]

⎜   ↳ Virtual core XTEST pointer              id=4[slave  pointer  (2)]

⎜   ↳ Logitech Unifying Device. Wireless PID:4004id=10[slave  pointer  (2)]

⎜   ↳ Logitech Unifying Device. Wireless PID:4017id=11[slave  pointer  (2)]

⎣ Virtual core keyboard                   id=3[master keyboard (2)]

↳ Virtual core XTEST keyboard             id=5[slave  keyboard (3)]

↳ Power Button                            id=6[slave  keyboard (3)]

↳ Power Button                            id=7[slave  keyboard (3)]

↳ Sony Power Control HID                  id=8[slave  keyboard (3)]

↳ HD Pro Webcam C920                      id=9[slave  keyboard (3)]

↳ SCEA Inc. Logitech USB Headset          id=12[slave  keyboard (3)]

[krislo]

Hi,

just entered forum to find if someone has exactly this problem. Can confirm same (mis)behavior on centos 7 + mate desktop.

brg

[fra81]

Thank you for the info!

We reproduced this issue with a wireless device and found the problem.

Here is the Trouble Report for tracking the issue: https://www.nomachine.com/TR10M06101. It will be fixed in the next update.

[fra81]

Hi krislo,

it is likely the same problem, but for a confirmation please send us the ‘xinput’ output from the server machine.

[Lantizia]

How does this answer point b) of my original post?

[krislo]

Hi,

thank you for prompt reply. Here’s xinput:

⥠Virtual core pointer                          id=2    [master pointer  (3)]
â   âł Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
â   âł HP HP                                     id=9    [slave  pointer  (2)]
⣠Virtual core keyboard                         id=3    [master keyboard (2)]
âł Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
âł Power Button                              id=6    [slave  keyboard (3)]
âł Power Button                              id=7    [slave  keyboard (3)]
âł HP WMI hotkeys                            id=10   [slave  keyboard (3)]
âź Silitek Standard USB Keyboard                id=8    [floating slave]

[loginatnine]

Hi!

First of all, good job on NoMachine, thanks for bringing a good RDP solution to Linux.

I have the same problem as described here on Linux Mint 17.1 on Cinnamon.

$ lsb_release -a

Distributor ID:LinuxMint

Description:Linux Mint 17.1 Rebecca

Release:17.1

Codename:rebecca

$ xinput

⎡ Virtual core pointer                    id=2[master pointer  (3)]

⎜   ↳ Virtual core XTEST pointer              id=4[slave  pointer  (2)]

⎜   ↳ USB KeyBoard                            id=11[slave  pointer  (2)]

⎣ Virtual core keyboard                   id=3[master keyboard (2)]

↳ Virtual core XTEST keyboard             id=5[slave  keyboard (3)]

↳ Power Button                            id=6[slave  keyboard (3)]

↳ Video Bus                               id=7[slave  keyboard (3)]

↳ Power Button                            id=8[slave  keyboard (3)]

↳ USB KeyBoard                            id=10[slave  keyboard (3)]

∼ Logitech USB Laser Mouse                id=9[floating slave]

 

[RedM]

I’d also be interested in the answer to b) How can I regain control over my host if the remote client is not accessible?

Example: From my computer at home I check some mails on my work machine with the first coffee in the morning. Later I go to work, but forget to disconnect the NX session on my home computer. At work I’m now facing a locked desktop with the NX session to my home computer still happily running. But with no obvious possibility to regain control and get in… except maybe killing the X Server or perhaps logging in via SSH and stopping the nxserver …

[domwells25]

Hi,

It’s great that this feature has been added, however there is another bug with it on Linux which is a bit of a security issue. When the screen is blanked someone can go up to the physical machine and hit Ctrl+Alt+F1 (or any of the F2-F6 keys) to switch tty and the F7 to go back to the X display to un-blank the screen without the remote user being aware. From then on the local user can take control.

I’m assuming I haven’t missed some config here? Hopefully this can be fixed in the next release?

Thanks

[fra81]

To answer ‘krislo’ and ‘loginatnine’:

thank you for the xinput output. It looks like the same problem of TR10M06101 and we confirm it will be fixed in the next update.

 

Regarding:

b) If I need to take back control of my PC without tracking down the client that is connected and disconnecting it, I can’t.

Not allowing to gain contol over the machine locally while the remote user is connected was intended as it seemed the safest choice. To unlock the screen in the scenario you describe, the user can connect with NoMachine from a different localtion and terminate the first connection. Alternatively the user could connect with SSH and do that from command line (‘/usr/NX/bin/nxserver –disconnect’ switch on linux, see ‘–help’ for further info, or ‘/usr/NX/bin/nxserver –restart’) or even switch to TTY locally with Ctrl+Alt+F* shortcuts, provided he has the required privileges for disconnecting the session or restarting the server.

 

About the bug reported by ‘domwell25’, we will check it and fix ASAP. Thanks for reporting!

[milosch]

I have seen a different issue where after connecting remotely with this feature enabled.  Upon returning to the machine at the office, the display is very distorted and unusable.  I have to crash X and log back in.  Not sure if this is related but it is new with this version.  I am using Centos 6.X.

[fra81]

Hi milosh,

that issue is known and it is tracked in this Trouble Report: https://www.nomachine.com/TR10M06095. The fix will be included in the next update.

[Author]

Posts