HNHacker News
TopNewBestAskShowJobs

arno1

224 karma · joined January 4, 2015

https://primal.net/andrey https://stacker.news

[ my public key: https://keybase.io/andreyarapov; my proof: https://keybase.io/andreyarapov/sigs/wxFmiwmLbUzfM8UU_gHt2EimV_KXM-iJBosgiidcWdg ]

submissionscomments
arno1··on Steam in Docker
Well, there is a distinct difference between traditional chroot and the Linux control groups and namespaces.

If only chroot was enough, noone would be investing their time to the cgroups, namespaces, LXC, Docker, etc... :-)

arno1··on Steam in Docker
Isolated or separated (from the host system). Both words will work when context is clear. Or it can confuse, when context was not specified, which is in my case.

What I actually meant is that I'd rather run an isolated (separated) process from other processes and the file-system space (and the other isolation features which cgroups are giving us), not meaning isolation from the host system.

With the cgroups/namespaces it's a process isolation (or separation, whatever wording you prefer). In the Linux kernel documentation they also use isolation wording. ;-)

arno1··on Steam in Docker
I bet there are dozens or maybe even hundreds of people who run CS in a container. What, I believe, makes the difference is that when one shares with the reproducible results. :-)
arno1··on Steam in Docker
The important part is to make sure that the ABI didn't change. Since Steam wants Debian-based distro, it then should be enough to keep the same. It's not a perfect way to go, but so far it works though. :-)
arno1··on Steam in Docker
@ingenter please refer to the docker-compose.yml file of the source repository.

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

arno1··on Steam in Docker
I haven't spotted the decrease. On the opposite, even some increase :-) (Or was that just a placebo effect? :) )

There actually shouldn't be any significant decrease since the Docker's overhead is negligible.

arno1··on Steam in Docker
Because Docker is enough and it does its job well? :-)
arno1··on Steam in Docker
I would say, using a Docker would move the vector of attack to a Docker engine and a Linux kernel implementation of cgroups, naming spaces.

But it would still help in preventing such bugs as https://github.com/valvesoftware/steam-for-linux/issues/3671

HN discussion: https://news.ycombinator.com/item?id=8896186

arno1··on Steam in Docker
Thanks @fasterthanlime !

Is there something that the firejail does better than the Docker?

I can see the firejail also uses the namespaces and seccomp-bpf.

arno1··on Steam in Docker
This thread is not about to what extent I trust things.

But security-wise, running it in a container is better, than running it without isolation. IMHO.

And of course, no one asks getting this image built by the 3rd party, since the Dockerfile is open, just build it yourself ;-)

arno1··on Steam in Docker
Yeah, one of the points which pushed me creating this image!

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 !

arno1··on Steam in Docker
@tormeh look at a Docker just like at a system that gets you the images (in "tar" archives) from the Docker Hub repo (or build them by yourself) and lets you run these "tar" images by leveraging the cgroups (Linux kernel abstraction feature that limits, isolates resource usage of a process). You may basically look at a Docker like at "chroot-on-steroids". And yes, it helps to run the images wherever you have Docker installed. There are few limitations though, especially when it comes to the point one needs to pass something from the host into a container (e.g. driver libraries, devices, special system paths or environment variables), since they may differ from distro to distro, from Platform to Platform.
arno1··on Steam in Docker
I think it should be pretty obvious why people put things into containers :-)

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.

arno1··on Steam in Docker
I haven't come up with a better idea obviously. :-) Suggestions/PR's are greatly welcomed!
arno1··on Show HN: True-Random – Generate “truly” random numbers
I think it is even worse than I thought...

I've asked the "true"-random tool to give me 3000 of the really "true" numbers (as it claims) and out of 3000 it has thrown to me ~9% of char(0) and ~9% of char(255) values (see the fractions below), whilst the others <0.01% per char between char(1-254).

  ./generate_constant_stream |head -c3000 |ent -c
  Value Char Occurrences Fraction
  0              309   0.103000
  1               33   0.011000
  ...
  ...
  253   �           28   0.009333
  254   �           29   0.009667
  255   �          312   0.104000
  Total:          3000   1.000000

  Entropy = 6.861709 bits per byte.

Update

Running it without the char(0)/char(255) neither did outperform /dev/urandom, but only running terribly slow (~5mins on i7) and using 100% of a CPU core:

  $ ./generate_constant_stream | cat - | sed -u 's/\x00//g;s/\xff//g' |head -c3000 |ent -c
  Entropy = 7.737683 bits per byte.

  $ cat /dev/urandom | sed -u 's/\x00//g;s/\xff//g' |head -c3000 |ent -c
  Entropy = 7.924493 bits per byte.
arno1··on Show HN: True-Random – Generate “truly” random numbers
The values presented are "N bits per character". 8 is the maximum, 0 is the minimum. The less value is the worse. The ugly test results show that "true"-random tool does not perform better than openssl / /dev/urandom. What makes it even worse is that the entropy decreases with the amount of iterations. These are simple bash tests, you can try on your own, playing with the values. Though, I suggest to understand some theory in the first place:

- randomness https://en.wikipedia.org/wiki/Randomness

- entropy https://en.wikipedia.org/wiki/Entropy_(computing)

- ent http://www.fourmilab.ch/random/

arno1··on Show HN: True-Random – Generate “truly” random numbers
ugly tests

1. ("true"-random) 10 iterations; 32 random bytes | Result Avg Entropy: 4.82

  $ echo $(echo -n "("; for i in $(seq 1 10); do echo -n $(./generate_constant_stream |head -c 32 |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/10") |bc -l
  4.81945500000000000000
2. ("true"-random) 100 iterations; 32 random bytes | Result Avg Entropy: 4.37

  $ echo $(echo -n "("; for i in $(seq 1 100); do echo -n $(./generate_constant_stream |head -c 32 |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/100") |bc -l
  4.37395291000000000000
3. ("true"-random) 200 iterations; 32 random bytes | Result Avg Entropy: 4.35

  $ echo $(echo -n "("; for i in $(seq 1 200); do echo -n $(./generate_constant_stream |head -c 32 |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/200") |bc -l
  4.34563333000000000000
1. (openssl) 10 iterations; 32 random bytes | Result Avg Entropy: 4.88

  $ echo $(echo -n "("; for i in $(seq 1 10); do echo -n $(openssl rand 32 |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/10") |bc -l
  4.88125000000000000000
2. (openssl) 100 iterations; 32 random bytes | Result Avg Entropy: 4.87

  $ echo $(echo -n "("; for i in $(seq 1 100); do echo -n $(openssl rand 32 |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/100") |bc -l
  4.87404420000000000000
3. (openssl) 200 iterations; 32 random bytes | Result Avg Entropy: 4.88

  $ echo $(echo -n "("; for i in $(seq 1 200); do echo -n $(openssl rand 32 |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/200") |bc -l
  4.87885575000000000000
1. (/dev/urandom) 10 iterations; 32 random bytes | Result Avg Entropy: 4.82

  $ echo $(echo -n "("; for i in $(seq 1 10); do echo -n $(head -c32 < /dev/urandom |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/10") |bc -l
  4.82264100000000000000
2. (/dev/urandom) 100 iterations; 32 random bytes | Result Avg Entropy: 4.89

  $ echo $(echo -n "("; for i in $(seq 1 100); do echo -n $(head -c32 < /dev/urandom |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/100") |bc -l
  4.88655640000000000000
3. (/dev/urandom) 200 iterations; 32 random bytes | Result Avg Entropy: 4.88

  $ echo $(echo -n "("; for i in $(seq 1 200); do echo -n $(head -c32 < /dev/urandom |ent |head -1 |awk '{print $3}')"+"; done; echo -n "0)/200") |bc -l
  4.88061280000000000000
← PreviousPage 2 of 2