Forum / NoMachine for Linux / Lock the physical screen when somebody connects doesn’t work as expected
- This topic has 17 replies, 8 voices, and was last updated 8 years, 10 months ago by
Britgirl.
-
AuthorPosts
-
October 1, 2015 at 12:13 #8452
Lantizia
ParticipantGot 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
October 1, 2015 at 12:32 #8457fra81
ModeratorHi 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.
October 1, 2015 at 17:48 #8462fra81
ModeratorWe 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.
October 7, 2015 at 09:29 #8515Lantizia
ParticipantUbuntu 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)]
October 7, 2015 at 10:25 #8526krislo
ParticipantHi,
just entered forum to find if someone has exactly this problem. Can confirm same (mis)behavior on centos 7 + mate desktop.
brg
October 7, 2015 at 10:25 #8531fra81
ModeratorThank 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.
October 7, 2015 at 10:29 #8532fra81
ModeratorHi krislo,
it is likely the same problem, but for a confirmation please send us the ‘xinput’ output from the server machine.
October 7, 2015 at 11:36 #8544Lantizia
ParticipantHow does this answer point b) of my original post?
October 7, 2015 at 11:37 #8541krislo
ParticipantHi,
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]October 8, 2015 at 09:59 #8572loginatnine
ParticipantHi!
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]
October 9, 2015 at 12:36 #8608RedM
ParticipantI’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 …
October 12, 2015 at 08:40 #8626domwells25
ParticipantHi,
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
October 12, 2015 at 09:52 #8643fra81
ModeratorTo 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!
October 12, 2015 at 13:56 #8648milosch
ParticipantI 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.
October 12, 2015 at 14:00 #8654fra81
ModeratorHi 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.
-
AuthorPosts
This topic was marked as closed, you can't post.