[X2Go-Dev] Mac OS X 10.4 Tiger

[Mihai Moldovan]

Hi,

with the latest changes, x2goclient will also run on Mac OS X 10.4. However, it
will not be officially supported.

While x2go is generally "use at own risk", this one is "use at own risk and
don't expect it to work properly."

Mac OS 10.4 is really old and unsupported even by Apple Inc. - not even with
security updates.

The X11 server version bundled with 10.4 is also old and known to cause color
problems. The X11 server is not meant to be updated by users in an easy and
convenient way, or at all. X11 server releases for 10.5 can't be installed on 10.4.

Generally, starting an X11 application on 10.5 and higher will automatically
launch the X11 server, if installed. This is due to structural changes in X11
integration implemented by Apple. On user login, an environmental variable
called "$DISPLAY" is set and points to a UNIX socket monitored by the system
daemon launchd. Whenever something tries to connect to this socket, the X11
binary is started.

This is not true for 10.4. On those systems, $DISPLAY is not automatically set
and thus not available from the initial environment.

Starting X11 manually will spawn an xterm instance with this env. var. set. From
this terminal application, other X11 applications could be launched just fine.
However, non-child-processes still won't be able to communicate with the X11 server.

Also, there is no easy way to know if an X11 server is already running, and if
it is, on which socket it's listening. My first idea was to implement some kind
of autodetection/probing for X11 sockets and connect to them in order to
determine whether they work or not. This said, at the same time valid security
concerns were raised. Connecting to unknown sockets is potentially dangerous,
and as the place those sockets are placed in is world-writable, anyone could put
a prepared socket in there. For obvious reasons, I dismissed this idea.

Instead, I am now probing for a free display number and launching a separate X11
server instance whenever it is needed. Existing instances/sockets won't be
re-used. This works fine, but obviously means that for every session a separate
X11 server is launched and the user has to clean up those instances by hand
(luckily each instance is shown as a normal application, so terminating those
processes is not a problem at all.)

This seemed like the safest, fastest and easiest way to go.

Another way would be searching the currently running processes for X11 and
examining the open files to find the socket, but this is way more complicated
and not really worth the effort.

Aside from that, the X11 server is listening for TCP connections by default and
there is no way/option to turn this behavior off, unlike in 10.5 and higher.
While the X protocol does have some security model based on the authcookies, I'm
really not too happy with exposing my X11 server to the whole network. At the
very least, evil users could crash the server. Evil geniuses may even obtain
root access in some way or another, especially with such an old and unmaintained
version.

I've only been rudimentary testing remote sessions, but as far as I see, opening
a new session, resuming and terminating works, at least with xterm as the remote
application. I can't really test this more thoroughly, as my test system seems
somewhat borked in X11 mode and is pressing "escape" after every key press. This
is also happening in local xterm sessions for me, but I haven't found any
information to this kind of misbehavior.
Not being able to test this stuff is just another good reason to not support it
officially.

This said, I guess I will publish new versions for 10.4 from time to time, for
those users who are bound to it and brave enough to use it. But again, if it
opens up anything visible, this is far more than you should even expect.

Best regards,


Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4493 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20120526/62be17e1/attachment.bin>