Opened 10 years ago

Closed 10 years ago

#13107 closed defect (fixed)

VBoxClient should not be started for remote X11 sessions -> fixed in 4.3 and later versions released after 21 July 2014

Reported by: Hrvoje Owned by:
Component: guest additions Version: VirtualBox 4.3.12
Keywords: Cc:
Guest type: X11 Host type: all



While playing with remote display sessions, i stumbled upon VBoxClient. Problem is that when you run Xsession over SSH, VBoxClient is started from Xsession.d script, and it does work as expected.

For example, ssh to server machine using "ssh -X", and make sure that on client machine you have X server willing to accept X protocol. Starting desktop environment using Xession command, will cause desktop to be started, but also VBoxClient.

In this case VBoxClient sees display on remote machine, and does not have access to VBoxService. For some reason, this causes some wierd efects, one of them is that user is unable to select any text in terminal, and do copy/paste operations. I did test this with latest Ubuntu, using Lubuntu as desktop.

My suggestion would be to add check in /etc/X11/Xsession.d/98vboxadd-xclient script wheter are we run as local X11 session or remote one. Simple check would be to see if there is SSH_CONNECTION environment variable, and it it is, then do not run VBoxClient. Another way would be to check for XDG_SEAT variable, and if it is there, run VBoxClient.

There is also another error there. Scripts in /etc/X11/Xsession.d are not executed, but instead, they are sourced. As such, they _must not_ contain "exit" directives! And current script for VBox have one exit inside. This must be removed.



Change History (7)

comment:1 by Michael Thayer, 10 years ago

I don't know if I am seeing the same as you here: I see something similar for the simple reason that I am ssh-ing into the virtual machine from the host system and this is causing a clipboard synchronisation loop: VBoxClient is running on the ssh X server which is proxying the host one and synchronising the clipboard to the host X server, so in effect trying to synchronise the host X server clipboard with itself.

The solution you propose would of course solve this, but I will have to think about it a bit.

comment:2 by Hrvoje, 10 years ago


Yes, i would say that this is quite similar to what i see. :-)

I think that it is safe to run without services, because in this case, they do not help.



comment:3 by Michael Thayer, 10 years ago

Sorry for the lack of response - I was unavoidably away from work for quite a while. Does this look alright to you? The code path which formerly contained the "exit" directive is actually no longer needed, as these days we refuse to support pre-release X server versions.

$ svn di src/VBox/Additions/x11/Installer/98vboxadd-xclient
Index: src/VBox/Additions/x11/Installer/98vboxadd-xclient
--- src/VBox/Additions/x11/Installer/98vboxadd-xclient	(revision 94874)
+++ src/VBox/Additions/x11/Installer/98vboxadd-xclient	(working copy)
@@ -21,29 +21,11 @@
     test -w $i || rm -f $i
-# Check whether the display we are running on running a known buggy version
-# of X.Org which might crash when we resize.
-found=`which Xorg | grep "no Xorg"`
-if test ! -z "$found"; then
-    if test -f "/usr/X11/bin/Xorg"; then
-        xorgbin=/usr/X11/bin/Xorg
-    else
-        exit 1
-    fi
+# Do not use "exit" here as this script is "source"d, not executed.
+if test -z "${SSH_CONNECTION}"; then
+  /usr/bin/VBoxClient --clipboard
+  /usr/bin/VBoxClient --checkhostversion
+  /usr/bin/VBoxClient --display
+  /usr/bin/VBoxClient --seamless
+  /usr/bin/VBoxClient --draganddrop
-xout=`$xorgbin -version 2>&1`
-if echo "$xout" | grep "1\.4\.99\.90[12345]" > /dev/null
-    no_display=1
-/usr/bin/VBoxClient --clipboard
-/usr/bin/VBoxClient --checkhostversion
-test -z "$no_display" &&
-    /usr/bin/VBoxClient --display
-test -z "$no_display" &&
-    /usr/bin/VBoxClient --seamless
-test -z "$no_display" &&
-    /usr/bin/VBoxClient --draganddrop

comment:4 by Michael Thayer, 10 years ago

By the way, I decided to use your idea of checking SSH_CONNECTION rather than something more generic on the grounds that this is the only case that we are currently aware of and I would prefer to avoid speculative generalisation until and unless we find more. I expanded the comment to say what we are actually doing...

comment:5 by Hrvoje, 10 years ago


I would say that this looks ok for me. :-)

Thank you.


comment:6 by Michael Thayer, 10 years ago

Summary: VBoxClient should not be started for remote X11 sessionsVBoxClient should not be started for remote X11 sessions -> fixed in 4.3 and later versions released after 21 July 2014


comment:7 by Frank Mehnert, 10 years ago

Resolution: fixed
Status: newclosed

Fix is part of VBox 4.3.16.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use