Unlocking virtual session (:1) sometimes unlocks physical session (:0)

[Felix Natter]

hello TurboVNC community,

I am using TurboVNC 3.0 on client and server. On machine A,
I start a VNC server:
 /opt/TurboVNC/bin/vncserver :1
Then I lock the session on A and go to machine B
(in this case they are in the same network, but in reality B could be remote)

On machine B I connect to A:1 using:

/opt/TurboVNC/bin/vncviewer -Toolbar=0 -Shared=0 -MenuKey=F2 \
-Encoding=Tight -JPEG=1 -Quality=70 -CompressLevel=7 -Subsampling=4x \
A:1

I lock virtual session A:1 from B, and when I login  again,
the physical session A:0 is also unlocked.

This is obviously a security problem.
If I log out cleanly on A (instead of locking the screen),
and redo the test, the problem is not reproducible any more
until I restart the VNC server on A.

~/.vnc/A:1.log looked unsuspicious (shall I post parts of it here?).

Also, if I do a switch user on a localhost:1 vncviewer session,
it triggers a switch user on :0. But I guess this is not supported.

Both machines are using Scientific Linux 7.9 ("Redhat7").

Many Thanks in Advance and Best Regards,
Felix

[DRC]

Switching users is definitely not supported, because the TurboVNC Server (Xvnc) process is owned by the user that started the TurboVNC session.  If you are using GNOME 3, then you are probably observing a symptom of this issue:

https://github.com/TurboVNC/turbovnc/issues/238

GNOME 3 is just generally not very multi-session-friendly.  You can successfully use GNOME 3 with multiple simultaneous TurboVNC sessions under the same user account, but per above, there are some known issues with screen locking.  Since most multi-user deployments of the TurboVNC Server are on headless systems without local login capabilities, disabling screen locking is a viable workaround for those systems.  In your case, you might want to consider a different window manager, such as MATE or Xfce, that is more multi-session-friendly.  You can use the $wm variable in /etc/turbovncserver.conf or ~/.vnc/turbovncserver.conf to specify that the TurboVNC Server should use a different window manager than the local session, which would allow you to continue using GNOME 3 with the local session.

As an aside, to the best of my (admittedly limited) understanding, this relates to two resources: the D-Bus session and the XDG session.  The TurboVNC Server creates a unique D-Bus session for every TurboVNC session, but all TurboVNC sessions running under the same user account will share the same XDG session.  That seems to be the root of the screen locking issues.  With TigerVNC, as an example, all VNC sessions under the same user account share both the D-Bus session and XDG session, so you can't start multiple simultaneous GNOME 3 instances under the same user account at all.  (Because all VNC sessions share the same D-Bus session, TigerVNC also doesn't allow multiple simultaneous instances of other window managers, such as MATE, that would otherwise work fine.)  We allow the same WM to be used with multiple simultaneous VNC sessions under the same user account, but there are some caveats when using GNOME 3.

DRC

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/865c852c-6741-42dc-a90e-96cd507c6608n%40googlegroups.com.