HN discussion: https://news.ycombinator.com/item?id=8896186
I regularly reference the # scary! comment at work.
I have tested HL engine based games and CS:GO which has its csgo_linux64 binary, causing lots of people to complain they could not run it, since Steam itself is 32-bit one. With this image it is not a problem, since I am preloading all the necessary libraries. It, though, still needs some polishing... @all: I appreciate your advice / PR !
* app isn't tied to / doesn't assume a Debian-ish distribution (we ship .deb, .rpm, a PKGBUILD, and a simple binary .tar.xz)
* app uses firejail on Linux (sandbox-exec on macOS, different user on Windows) to "set up more fences around" games you download from the internet.
I don't want to spam links, but if you're interested in our approach, you can probably search "itch.io sandbox" with your favorite search engine and stumble upon it :)
Is there something that the firejail does better than the Docker?
I can see the firejail also uses the namespaces and seccomp-bpf.
If I'm not mistaken, containers come with their own userland, if you want a useful graphical container you're in for a few hundred megabytes of dependencies, whereas sandboxing approaches (firejail, projectatomic/bubblewrap - used by flatpak for example) just try and limit what a process in the same user space has access to.
I wanted a solution that was low-overhead enough that it was a no-brainer for users to turn it on. However, it's not perfect: our sandbox policy could use tightening (as long as it doesn't break too much stuff), and having an additional SUID binary around is definitely something to look out for.
I'm hoping that more interest gathers around sandboxes and that they become more mainstream in Linux ecosystems. "Trusting package maintainers" only goes so far, and doesn't really account for third-parties shipping binary packages!
https://wiki.archlinux.org/index.php/PulseAudio/Examples#Pul...
Forgot exactly what I did with X11, but one part of it was having an environment variable that used my main users XAuthority
E.G. [gamer@mycomputer]$ echo $XAUTHORITY
/home/notthemessiah/.Xauthority
"Those who do not understand UNIX are condemned to reinvent it, poorly." -- Henry Spencer, programmer
This goes doubly for "containers" not understanding chroot/jails.
If only chroot was enough, noone would be investing their time to the cgroups, namespaces, LXC, Docker, etc... :-)
Containers provide chroot-like behavior for more than just the filesystem. Processes, user IDs, network interfaces... Chroot is filesystem only.
Or is this an exercise in getting GUI applications with slightly exotic features (GPU access) to run?
I'd like to understand why this was made but it isn't described in the usage instructions.
Few main points though, which pushed me making this Docker container:
1. I want to set-up more fences when running the code I don't/can't trust;
2. I don't want to spend time on figuring out how to install Steam (what deps) in a non-Debian (or non-SteamOS) based distro;
3. I like cleanliness: I can erase Steam and all its dependencies in a matter of seconds;
4. Like you said, it was an interesting exercise and it still needs some polishing :-)
And few Pros from my PoV:
- I can have Steam on my Ubuntu/openSUSE/[put any other distro I will want to use] in a short time that Docker takes when downloads this Steam container;
- Since Steam is meant to run in Debian (SteamOS) based distro, it is not a problem anymore, since it is in a container now.
This looks really promising though, and shows a practical use case for docker.
But changing just one line in a docker-compose.yml file you can mount it wherever you want on your host. See "data:/home" in there.
You can write there "/home/your-user/mysteamdata:/home", so that all Steam games (caches, saves, ...) will be available for you at your home directory in "mysteamdata" directory ;-)
Is there a better way?
It automatically discovers the devices and the right driver files on the host.
The main goal is compute (CUDA), but we also demonstrated how to run TF2 on Steam OS during our DockerCon 16 OpenForum presentation.
Nice job! :)
This will give you a frame rate identical to your host, so there is no overhead running your 3D apps in the container.
I'm not very familiar with using Docker.
https://youtu.be/ZHWsR8TnKsw?t=801
PS: Audio is in spanish.
Then as discussed in this thread, it gives few security advantages, control benefits since those isolated resources are controllable.
To make pulseaudio work in a container, you basically want to pass these volumes from the host to a container:
- /etc/localtime:/etc/localtime:ro
- /etc/machine-id:/etc/machine-id:ro
- $XDG_RUNTIME_DIR/pulse:/run/user/1000/pulse
And then, this environment variable:
PULSE_SERVER=unix:$XDG_RUNTIME_DIR/pulse/native
IE how many FPS do you get with a native Steam install vs Dockerized Steam on the same hardware?
The precise testing haven't been done explicitly to measure increase/decrease. But feel free to test it. ;)
There actually shouldn't be any significant decrease since the Docker's overhead is negligible.