Unable to start X11 programs.

[ypid]

subuser run keepassx
Traceback (most recent call last):
  File "/var/local/testuser/subuser/logic/subuserlib/classes/subuserSubmodules/run/x11Bridge.py", line 171, in mkdirs
    self.getUser().getEndUser().makedirs(directory)
  File "/var/local/testuser/subuser/logic/subuserlib/classes/endUser.py", line 68, in makedirs

When you strace this it seems that it is going thought the whole filesystem.

access("/usr/bin/xfce4-settings-manager", X_OK) = 0
stat("/usr/bin/dpkg-gensymbols", {st_mode=S_IFREG|0755, st_size=10500, ...}) = 0
access("/usr/bin/dpkg-gensymbols", X_OK) = 0
stat("/usr/bin/nicstat", {st_mode=S_IFREG|0755, st_size=31032, ...}) = 0
access("/usr/bin/nicstat", X_OK)        = 0
stat("/usr/bin/cal", {st_mode=S_IFREG|0755, st_size=29776, ...}) = 0
access("/usr/bin/cal", X_OK)            = 0
stat("/usr/bin/rst-buildhtml", {st_mode=S_IFREG|0755, st_size=9962, ...}) = 0
access("/usr/bin/rst-buildhtml", X_OK)  = 0
stat("/usr/bin/delpart", {st_mode=S_IFREG|0755, st_size=18632, ...}) = 0
access("/usr/bin/delpart", X_OK)        = 0
stat("/usr/bin/xfce4-mime-settings", {st_mode=S_IFREG|0755, st_size=55336, ...}) = 0
access("/usr/bin/xfce4-mime-settings", X_OK) = 0
stat("/usr/bin/col1", {st_mode=S_IFREG|0755, st_size=963, ...}) = 0
access("/usr/bin/col1", X_OK)           = 0
stat("/usr/bin/lzfgrep", {st_mode=S_IFREG|0755, st_size=5421, ...}) = 0
access("/usr/bin/lzfgrep", X_OK)        = 0

The programs does this for a few minutes then it terminates with:

  File "/var/local/testuser/subuser/logic/subuserlib/classes/subuserSubmodules/run/x11Bridge.py", line 163, in cleanUp
    self.getUser().getDockerDaemon().execute(["run","--rm","--volume",os.path.join(self.getUser().getConfig()["volumes-dir"],"xpra")+":/xpra-volume","--entrypoint","/bin/rm",self.getServerSubuser().getImageId(),"-rf",os.path.join("/xpra-volume/",self.getSubuser().getName())])
  File "/var/local/testuser/subuser/logic/subuserlib/classes/docker/dockerDaemon.py", line 226, in execute
    return subuserlib.docker.run(args,cwd=cwd)
  File "/var/local/testuser/subuser/logic/subuserlib/docker.py", line 52, in run
    return subprocessExtras.call([getAndVerifyExecutable()]+args,cwd)
  File "/var/local/testuser/subuser/logic/subuserlib/subprocessExtras.py", line 20, in call
    process = subprocess.Popen(args,cwd=cwd)
  File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.4/subprocess.py", line 1386, in _execute_child
    for dir in os.get_exec_path(env))
  File "/usr/lib/python3.4/os.py", line 588, in get_exec_path
    with warnings.catch_warnings():
RuntimeError: maximum recursion depth exceeded

Running non X11 programs like Vim works fine.

[timthelion]

This is using the latest subuser from git? I don't have this problem, but I'm certainly looking into it.

[ypid]

Yes I was using latest master.

[timthelion]

Can you please pull the latest master and give me the full output of:

$ SUBUSER_DEBUG_XPRA=TRUE SUBUSER_VERBOSITY=5 subuser run keepassx

[ypid]

I put the logs here: https://github.com/ypid/subuser-x11-xpra-issue Test system is a Virtualbox VM running Debian Jessie but I was also testing on a bare metal Debian Jessie system. Maybe you can reproduce this also.

Just a note. I am going with Firejail for lightweight compartmentalization in AppVMs https://github.com/ypid/firejail-scripts I got xpra working with it. Thanks again for your work :+1:

[timthelion]

I just noticed: /var/local/testuser Is that really the value of $HOME? It seems the problem is a permissions problem in writting to that directory... I'm still not sure what could be causing thhat, because it appears that subuser has no problem writting to that directory up till that point.

[timthelion]

What is the reason you chose to go with firejail? Disk space usage? Or seccomp support? Something else?

[ypid]

I just noticed: /var/local/testuser

Yes. That is really the $HOME. The test system has been setup using Ansible and https://github.com/debops/ansible-bootstrap. Also not sure. I did run it on a normally configured desktop system with the same issue. Maybe you are able to reproduce this bug in a Debian Jessie environment.

What is the reason you chose to go with firejail? Disk space usage? Or seccomp support? Something else?

Makes sense to write a short comparison now that I know both a bit. So here it is:

Pro Subuser:

• The program is running in its own chroot image which has nothing to do with the main system. (This was the main reason I checkout out Subuser again and is a big plus)
• Only white listing approach. There is no "most stuff is allowed and only certain things are blacklisted" (related to filesystem access).
• It uses not a self written sandboxing implementation like FireJail does (utilizing Linux kernel features directly) but is based on a widely used container software (despite the security problems with Docker).
• It allows to update the main system while containers are running. Something I found is not as easy with FireJail as it bind mounts some stuff and so on which seems to lock system files. (This does not matter when you run Qubes OS as you would update the template VM instead).
• I like the concept of having subusers very much because this is my main use case. This will also make it very easy to move to a compartmentalized OS like Qubes OS later because you only need to distribute you sandboxes to the different AppVMs. FireJail also supports this using the --private=$NEW_HOME_DIR flag.

About equal:

• Subuser can get root via Docker. FireJail is SUID root.
• Both work with xpra. FireJail has no builtin support right now (edit: added as of 2016-02-27).
• Getting started with.

Pro FireJail

• Easier to maintain. No duplicate installations. I think the attack surface of the actual package installation is low and if one really cares about this they would use Qubes with different templates anyway. But without Qubes OS I would strongly prefer to have package installation also contained in a sandbox.
• Just opening a new sandbox is really easy. If I want to try something I can just use something like firejail --net=nat0 --netfilter=/etc/firejail/nolocal.net --private and get a sandbox test environment. Subuser is more centered on only running one program in its own sandbox. What I like to have is just a shell in the sandbox and then do stuff there. On the other hand, I can also use Docker directly for this.
• Better protection against exploits (https://github.com/subuser-security/subuser/issues/269), Seccomp
• Better root/user separation e.g. members of the docker group are effectively root. Having SUID FireJail installed hopefully does not mean the same …
• It is similar to Subgraph OZ in that I could also set it up for not so technical people. (E.g. handle system updates in one place)
• It is in Debian Stretch (edit: also in jessie-backports by now)
• It is more standalone.
• It can be combined with AppArmor (because it does not use different file paths, normal AppArmor profiles still restrict applications running in FireJail).
• It can log security violations.

Conclusion. I use FireJail for most things. I might consider using Subuser for example when I want to install packages from Debian unstable (althought I found it easier to just fall back to using Docker directly once I had a need for this (OK, quite a special case which probably does not count because of x86-32): https://github.com/ypid/docker-libreoffice-duden). I hope that gave you some insight's from a users perspective. Thanks again for your work.

[timthelion]

Reproduced and fixed. This is a nasty-reoccurant bug which is caused by launching a Docker container with a volume that points to a non-existant directory on the host. When you do that, Docker automatically creates the directory and the directory that is created by Docker is owned by root.

[timthelion]

Thanks a lot for your patience in reporting this. And also thanks for the thourough analysis of subuser and firejail. I will definitely take your sugestions into account.

[ypid]

Thanks very much for the fix :+1: