usermod: group 'docker' does not exist

Setting up gitlab-ci-multi-runner (0.3.4-1-ge9b0e04) ...
usermod: group 'docker' does not exist
gitlab-ci-multi-runner start/running, process 10313

@ayufan any idea what causes this warning message during the package installation? Seen on Ubuntu 12.04.

I hope we are not trying to add the gitlab_ci_multi_runner user to the docker group.

Kamil wrote:

Yes, it works that way: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/security/index.md#systems-with-docker-installed

Thanks for the link.

I think this is dangerous behavior. As documented in the link, 'docker' group membership on a system with docker installed is equal to root access.

The package will always create the 'gitlab_ci_multi_runner' user. Depending on whether your system has docker installed, this user has superuser privileges. This is unpredictable. Consider the following scenario: I set up gitlab-ci-multi-runner with the 'shell' executor on my system, intending the 'gitlab_ci_multi_runner' user to be an unprivileged user. Then some time after that, I install Docker on the same system for some other use case. Now I run 'apt-get upgrade', gitlab-ci-multi-runner gets upgraded, and all of a sudden my gitlab_ci_multi_runner user (which I thought was unprivileged) gets root access via the 'docker' group.

cc @sytses

I think we should pick one behavior: add the gitlab_ci_multi_runner user to the docker group by default or not. Not 'if the docker group exists'.

Adding to the docker group by default makes the 'shell' executor unsafe, so I am leaning towards not adding the gitlab_ci_multi_runner user to the docker group by default.

@jacobvosmaer what happens if you do it by default and the docker group is not there?

can we add only on install, not on upgrade?

what happens if you do it by default and the docker group is not there?

Then you get the warning message in the issue title. That is easy to fix (redirect stderr to /dev/null).

can we add only on install, not on upgrade?

That is still unsafe in the scenario where I have Docker installed for my own reasons, and I want to do unprivileged shell builds with gitlab-ci-multi-runner.

@jacobvosmaer I think doing it only on install is an acceptable tradeoff. What do you think @ayufan ?

@sytses It's good idea.

Ideally to make it more secure - executing shell scripts: We can run builds with dropped permissions and as separate user/group.

In that case gitlab-runner would be run as root, but in order to execute build it will setid it to gitlab-runner. That way we could safely store runner configuration and don't require to add docker group to user unless user wants to docker build from job.

@jacobvosmaer what do you think?

Added improvement label

+1 for running as root and doing a privilege drop for the shell executor.

I think doing it only on install is an acceptable tradeoff

@sytses I strongly disagree with this. Luckily, shifting the runner to use root as suggested by @ayufan above sidesteps this issue.

Running as root sucks, relatively speaking, but at least it would be predictable and justifiable. 'Privilege separation roulette' with the docker group is neither.

Glad we're able to sidestep the issue, thanks!

I like it, but let's schedule it for 0.5.0.

Milestone changed to v0.5.0

@jacobvosmaer https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/92

Status changed to closed