search

SinusBot / docker

🐳 Official Docker image of the SinusBot for TeamSpeak 3 and Discord.
https://sinusbot.github.io/docker
MIT License
78 stars 32 forks source link

Running as root #27

Closed gimicze closed 5 years ago

gimicze commented 5 years ago

What is the reason for running the Sinusbot as root? This is the official docker image of it, isn't it? Aren't you discouraging people to run it as root? Please fix this.

irgendwr commented 5 years ago

Aren't you discouraging people to run it as root?

Yes, because it's good practice in general.

What is the reason for running the Sinusbot as root? This is the official docker image of it, isn't it?

Running a service inside a docker container as root is not the same as running a service on your "real" server as root. In this case the SinusBot is only running as root inside the docker container. The container is (mostly) isolated from your actual server.

One could argue that even though the container is isolated you should still run the service with as few permissions as possible. That's true but makes things a bit more complicated.

We're using volumes for the scripts and data folder, if we change something then the volumes might not be writable. (haven't looked into this though, not sure but it's not that simple)

If you have a solution then feel free to make a pull request. ^^

If users wants to run the container properly with as few permissions as possible: They have the possibility to do it already. They can use dockers --userns-remap ... or --user ... flags/parameters to set the user. You will however need to change the ownership of the volumes accordingly.

irgendwr commented 5 years ago

A majority of docker images run as root in their container, including the official TeamSpeak image.

gimicze commented 5 years ago

Yes, many docker images run as root, but I don't see a reason here as there is another Sinusbot docker image which doesn't run it as root. And don't get me wrong, I was just curious and it's not that much of a problem. I may have a look at it sometime.

irgendwr commented 5 years ago

Yep, previous versions of the sinusbot would refuse run as root in docker-containers but we decided that in that case it would make sense to add an exception.

I'm leaving this issue open for now and we'll probably look into it sometime. The only thing that worries me is that users will need to change ownership of the volumes which will probably lead to people complaining that their docker container is no longer working/"has a bug". Dunno, we'll see.

Xuxe commented 5 years ago

Aren't you discouraging people to run it as root?

Yes, because it's good practice in general.

What is the reason for running the Sinusbot as root? This is the official docker image of it, isn't it?

Running a service inside a docker container as root is not the same as running a service on your "real" server as root. In this case the SinusBot is only running as root inside the docker container. The container is (mostly) isolated from your actual server.

One could argue that even though the container is isolated you should still run the service with as few permissions as possible. That's true but makes things a bit more complicated.

We're using volumes for the scripts and data folder, if we change something then the volumes might not be writable. (haven't looked into this though, not sure but it's not that simple)

If you have a solution then feel free to make a pull request. ^^

If users wants to run the container properly with as few permissions as possible: They have the possibility to do it already. They can use dockers --userns-remap ... or --user ... flags/parameters to set the user. You will however need to change the ownership of the volumes accordingly.

As @irgendwr said it's more up to the admin to configure a privilege downgrade e.g remapping the user ids: https://docs.docker.com/engine/security/userns-remap/ https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups

I don't recommed to change things like this if you have already running containers, you will destroy all volumes with it, because as already said you have to remap the uids.

Dropping the privileges with a "default" user inside the dockerfile is a "work a round" to make it secure by default but this may colides with other user ids on the host. I may use the id 1000 inside the dockerfile and have an existing user on the host with id 1000 and extended privileges. I think you get it, it's may a mess if you have running containers with a user id of a host user.

But we should take a note inside the docs/install instructions about this topic @irgendwr .