Support runing as non-root
MeFisto94 opened this issue · 4 comments
Especially it environments like tor, I'd like to have processes not run as root.
Usually one can simply specify a user from docker run (or docker-compose) to use, however that fails like this:
Jun 05 19:32:57.937 [warn] Error creating directory //.tor: Permission denied
Jun 05 19:32:57.937 [warn] Failed to parse/validate config: Couldn't access/create private data directory "//.tor"
As the root-filesystem is owned by root.
Some Images tackle that by simple adding a user with the id 1000 and running from it's home directory, however docker hosts might prefer to define their own UID/GID to be used.
I think the best solution therefore would be a special folder /tor (e.g.) which is world read/writeable, that way we would avoid creating a new user each time the container is run with a different userid.
One might also want to expose that as a volume, so the user could inspect logs and/or change the configuration.
Then world-readability is a bit dangerous though, as with bind-mounts the tor configuration is exposed to every user on the host.
Edit: Or simply have something like this https://github.com/dperson/torproxy/blob/master/torproxy.sh#L128, however I'd still prefer the world-writeable folder I think
Edit2: Okay so far this is looking bad:
0
Jun 05 20:07:05.269 [warn] /tor is not owned by this user (<unknown>, 1000) but by <unknown> (0). Perhaps you are running Tor as the wrong user?
Jun 05 20:07:05.269 [warn] Failed to parse/validate config: Couldn't access/create private data directory "/tor"
Which means Tor is recognizing the "misconfiguration" and hence refusing to work, so I'll try the dpersion/torproxy approach
Any pros and cons of it? I'm not very familiar with using non-root user inside Docker image yet, but for micro and very specific purpose image, I'm not sure if we need it, would like to heard more details, thanks.
Hey,
What most people forget is that a container is not a protection like a VM would be, instead the docker processes run like regular processes on your Operating System and as such it's generally not advised to have them run as root. Just imagine you'd have a vulnerability in tor. I can't judge how hard it is to "break out" of docker (because the filesystem is limited to fakeroot, but maybe one could load kernel modules and such?), but when possible one should avoid that.
Another thing would be if one would want to access the /tor volume (granted this problem only appears due to my pr), then all files would be owned by root. With the USERID Environment Variables one can specify the UID of the currently running user on the host (id) and then can access the files without root access.
Edit: And I can't really think about cons since tor was made to run as non-root. The only thing could be the additional "complexity" due to the environment variables
Hi @MeFisto94,
As you didn't respond in the PR #5 you sent, I decide to use a simple method to solve the user issue, take a look please, not as powerful as the PR you send, but should be good enough to resolve this issue.
Of course, you can still send a enhancement pull request when you have time, thank you for your contribution!
I've tested e1c9016 for a while, and it's published recently.
Now we limit the whole tor process inside tor user, not even let it setuid/setgid by itself, which is more secure.
The powerful user mapping feature is still not implement yet, if anyone think it'll be very helpful, please feel free to send another pull request based on the latest code base :)