docker_socket should be tied to docker_group by default

[puppetlabs]

docker_socket should be tied to docker_group by default

[davejrt]

If you don't specify this, it defaults to docker anyway, and I agree with the logic that @LongLiveCHIEF has presented it here. I'm happy to set a the default in the module as you've suggested in your first comment @trevor-vaughan and give the user the ability to change it if they wish.

[davejrt]

Historically I'm not sure what the motivation was to have them separate and not set a default, but I'll look into it and provide feedback shortly

Can you link to the docs you're referring to?

[LongLiveCHIEF]

Yes, it's valid that they could be different depending on the configuration settings.

The docker_group is allowed to run docker commands without using sudo. This can be done even while the socket_group is root, allowing tighter security and control of the docker daemon, especially on selinux enabled systems.

If you make them the same, then anyone who can run any old docker command, would also be able to run any dockerd command, also without sudo. You probably don't want that.

[trevor-vaughan]

@LongLiveCHIEF Maybe I'm missing something. What docker commands are useful without being able to communicate with the socket? This may be pure user error on my part.

[trevor-vaughan]

@davejrt The documentation is the dockerd command line docs at https://docs.docker.com/engine/reference/commandline/dockerd/#description

The group options is "Group for the unix socket" and dockerd does not connect to TCP or FD by default

Per the Daemon socket option section

By default, a unix domain socket (or IPC socket) is created at /var/run/docker.sock, requiring either root permission, or docker group membership.

If you want to prevent the ability to run dockerd commands, I suppose you could have the daemon listen to 127.0.0.1:2375 by default. I haven't tried the fd option so that may be what I'm missing.

[LongLiveCHIEF]

You're conflating socket ownership with the usage of the socket's clients. the socket can be owned by root and still be communicated with by a non-root user, depending on how access and commands are set up on the system in question.

…

On Sat, Jan 6, 2018 at 2:01 PM, Trevor Vaughan ***@***.***> wrote: @LongLiveCHIEF <https://github.com/longlivechief> Maybe I'm missing something. What docker commands are useful without being able to communicate with the socket? This may be pure user error on my part. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADIVgRtfHsIdGu3y-NEwxbx13LM1ceu8ks5tH9EzgaJpZM4RSCwH> .

[trevor-vaughan]

@davejrt Thanks, I think that will make everything more like users expect.

@LongLiveCHIEF Can you provide an example of this? I'm honestly not following.

From a system set up with the module where vagrant is in docker_users and the docker_group is set:

[root@server01 ~]# ll /var/run/docker.sock 
srw-rw----. 1 root root 0 Jan  7 02:57 /var/run/docker.sock

[vagrant@server01 ~]$ docker ps
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

[root@server01 ~]# chgrp dockerroot /var/run/docker.sock 
[root@server01 ~]# ll /var/run/docker.sock 
srw-rw----. 1 root dockerroot 0 Jan  7 02:57 /var/run/docker.sock

[vagrant@server01 ~]$ docker ps
CONTAINER ID        IMAGE                                                 COMMAND                  CREATED             STATUS              PORTS                    NAMES
13df051d2333        server01.int.localdomain:5000/custom_nginx_server02   "nginx -g 'daemon off"   5 minutes ago       Up 5 minutes        0.0.0.0:8081->80/tcp     custom_nginx_server02
681823acca51        custom_nginx_server01                                 "nginx -g 'daemon off"   5 minutes ago       Up 5 minutes        0.0.0.0:80->80/tcp       custom_nginx_server01
e7ea608588fa        server01.int.localdomain:5000/custom_nginx_server03   "nginx -g 'daemon off"   5 minutes ago       Up 5 minutes        0.0.0.0:8082->80/tcp     custom_nginx_server03
33935e3b6a2e        registry                                              "/entrypoint.sh /etc/"   5 minutes ago       Up 5 minutes        0.0.0.0:5000->5000/tcp   registry

@LongLiveCHIEF In your opinion, what is the proper method for doing this without allowing write access to the socket and/or what should the module do by default?

I think that what you're getting at is setting up a localhost TCP connection by default per https://docs.docker.com/engine/security/https/, but that's not the configuration that the module presents out of the box nor is it suggested in the README from what I can tell. Should this be the default?

Honestly, my main use case for the docker_group is GitLab CI runners and it would be nice to not expose any additional services/ports on my system that I don't have to. Obviously, anyone in the docker or dockerroot (RHEL) group is going to be able to do what they like with docker containers and there are no users in that group by default.

[LongLiveCHIEF]

This module is still working on catching up on some things, and the daemon settings is a big one of these.
The daemon used to be tied to the docker client library, but this was broken out a while ago, and is now a completely different command.

In a simplified way of looking at it... socket_group is tied to dockerd command usage, whereas docker_group is tied to docker command usage.

[scotty-c]

closing due to #107 being merged

[trevor-vaughan]

I would like to re-open this since it appears to have gotten reverted per #133

[davejrt]

Fixed in PR #133

[esalberg]

1. The readme and init.pp files still state that the default for $socket_group is undef.
2. We try not to restart the Docker daemon randomly (I know, our app teams are learning). This change add -G docker, and I don't believe there's any way for me to work around it (obviously, setting socket_group => undef in my profile doesn't work, since undef doesn't override).