Steam client escaping lxd?

Hi here,

I’ve been using steam to play games under lxd (version 3.9) for some time now, and was happy with it.
The profiles are (config taken from

$ lxc info steampowered 
Name: steampowered
Location: none
Remote: unix://
Architecture: x86_64
Created: 2018/08/08 12:38 UTC
Status: Stopped
Type: persistent
Profiles: default, gui

Default profile is:

$ lxc profile show default 
config: {}
description: Default LXD profile
    nictype: bridged
    parent: lxdbr0
    type: nic
    path: /
    pool: main_lxd_storage_pool
    type: disk
name: default

And gui is:

$ lxc profile show gui
  environment.DISPLAY: :0
  raw.idmap: both 1000 1000
  user.user-data: |
      - 'sed -i "s/; enable-shm = yes/enable-shm = no/g" /etc/pulse/client.conf'
      - 'echo export PULSE_SERVER=unix:/tmp/.pulse-native | tee --append /home/ubuntu/.profile'
      - x11-apps
      - mesa-utils
      - pulseaudio
description: GUI LXD profile
    path: /tmp/.pulse-native
    source: /run/user/1000/pulse/native
    type: disk
    path: /tmp/.X11-unix/X0
    source: /tmp/.X11-unix/X0
    type: disk
    type: gpu
name: gui
- /1.0/containers/steampowered

Yesterday, steam triggered an upgrade and downloaded a new version of the client into my main desktop (in ~/.steam/ and ~/Steam of my main directory).

Notice my Gnome desktop runs under wayland.

Does anyone have an idea how it is possible that steam triggers a download and install outside of its container ?


Hmm, so one idea is that it may have been able to talk to some other piece of your desktop through the X socket? effectively causing a URL to be opened outside of the container?

That still feels a bit weird though.


You must be running Wayland with that X11 compatibility package that make it possible to use X11 in the container. It should not make a difference though with what we are discussion here.

Can you tell me what distribution you are running?

By following my tutorial, the host shares the X11 server socket with the container, meaning for example, that a malicious X11 app in the container can potentially perform all sorts of things on GUI apps on the host over the X11 Unix socket. Cannot access the memory of apps on the host, cannot access the filesystem of the host, but can access the Unix socket of X11.

Let’s run xdg-open in the container to open a URL. Here, there is no browser installed in the container, and this app will try to find the suitable application from within the container. So, it was probably not xdg-open.

ubuntu@steam:~$ xdg-open
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: x-www-browser: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: firefox: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: iceweasel: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: seamonkey: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: mozilla: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: epiphany: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: konqueror: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: chromium: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: chromium-browser: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: google-chrome: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 851: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening ''

Nor with dbus-send which is used to instruct apps to perform things because they (host and container) do not share the socket at /var/run/dbus/system_bus_socket. There is no dbus-x11/dbus-launch installed either by default. You can also try with d-feet in the container to see if you can get any info that relates to the host.

Let’s go back to X11 and what can be gleaned out from the X11 Unix socket.
The following command, when you run it from within the container, will show the list of applications running on the host (and also container, like Steam).

xwininfo -root -tree

You can try to figure out how to instruct applications from within the container using a tool like xdotool, which uses the X protocol. By doing so, you can avoid writing an Xlib program instead.
We notice that there is a xdotool exec subcommand that instructions X11 to run programs.
Let’s run this in the container. It opens xeyes. Note that both the container and the host have xeyes.

xdotool exec /usr/bin/xeyes

Let’s try with something that exists on the host but not in the container. The container has no easy mechanism to run programs on the host.

$ xdotool exec /usr/games/gnome-sudoku
execvp failed: No such file or directory

Having tried all these, I think the important aspect is that only a malicious program would be able to perform bad things through the X protocol. I am sure that it is possible to build some sequence of commands to run code on the host. But I cannot think of a way for the steam client instructing the host to install Steam. In fact, Steam performs any update internally without prompting the user to download or run a program.

It would be helpful if you could describe the window that opened and prompted you to install Steam. It would be good to figure out whether it was Steam or something else that installed Steam on the host.

Hi, and thanks for the feedback.

Here is my ps aux | grep steam while running steam in LXD:

Does it make sense ? (and does steamwebhelper run outside the container ?)



The typical commands like ps and top are not clear as to whether a process runs on the host or in a container. And in these gui containers, we have set the id mapping so that your user ID on the host matches that in the container. Therefore, the steam process appears to be running as your userid on the host but it is indeed running in the container. From the host you can view and even kill the processes that run in the container, but from inside the container you do not see the other processes from the host.

Having said that, you can use pstree which will show you the hierarchy of the processes.
What you need to look for, is that any Steam processes should be found only under the lxd process.
If you find a Steam process elsewhere in the process tree, then that’s a valid concern.

Note that there are some updated instructions at