Glenn Faden's Blog

  • January 25, 2009

Improving X11 Performance and Security

Guest Author

The X11 server in OpenSolaris is configured using the limited_net service profile (Secure by Default) so that it does not listen for TCP connections. Instead, it relies on the local transport, UNIX domain sockets. When Trusted Extensions is enabled via the SMF labeld service, this restriction is relaxed to allow some TCP connections. This was necessary because UNIX domain sockets could not be used for the cross-zone access required by X11 clients running in labeled zones. To minimize the risk, the X11 server rejects connection from untrusted X11 clients. However, this solution was not ideal because TCP connections are slower than UNIX domain and require network connectivity between labeled zone clients and the global zone X11 server.

Starting with OpenSolaris 2008.11, UNIX domain socket can now be used by labeled zone X11 clients, but the configuration does not yet work be default. The workaround is fairly simple, and actually reverses a previous workaround that I described last July. Here are the steps:

# mkdir -p /etc/dt/config

# cp /usr/dt/config/Xinitrc.tjds /etc/dt/config

In the new Xinitrc.tjds file, change the setting for the DISPLAY variable and add the following mount command

# Workaround Xconnecion problem
export DISPLAY=unix:0
mount -F lofs /tmp/.X11-unix /var/tsol/doors/.X11-unix

Then you can disable the TCP listener in the X11 server as follows:

# svccfg -s x11-server setprop options/tcp_listen=false

These changes will take effect on the next login. This configuration makes it easier to use exclusive IP stack instances, since the X11 clients no longer need any access to the global zone's network. I'll explore that more fully in my next blog entry.

Join the discussion

Comments ( 1 )
  • ed hardy boots Tuesday, March 9, 2010

    This is a nice post.

    I feel so exciting aftering seeing it.

    Many thanks.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.