Description of problem: The removal of docker.socket and the docker user/group mean that docker cannot be used as part of the cockpit console anymore (using non-root accounts). This is because, although users can be added to the dockerroot group, the permissions of the sockets are reset upon docker restart. Version-Release number of selected component (if applicable): docker-io-1.5.0-1.fc21.x86_64 cockpit-0.27-3.fc21.x86_64 / cockpit-head Steps to Reproduce: 1. Add user to dockerroot 2. chown docker socket to root:dockerroot 3. Call a docker command from user (succeeds from CLI and cockpit) 4. restart docker 5. Call a docker command from user (fails from CLI and cockpit) Actual results: Ownership of docker socket are reset to root:root Expected results: Ownership of docker socket should be configurable and compatible with cockpit Additional info: related to https://bugzilla.redhat.com/show_bug.cgi?id=1192848 Relevant change in the rpm spec: "* Fri Jan 16 2015 Lokesh Mandvekar <lsm5> - 1.4.1-7 - docker group no longer used or created - no socket activation - config file updates to include info about docker_transition_unconfined boolean"
Hi Benjamin, assuming you haven't added a dockerroot group yourself, please note: the default 'dockerroot' created by the rpm is a user and not a group. So root:dockerroot won't work as expected. If you'd like non-root users (users in group 'docker' for instance) to be able to use docker, simplest would be to append the -G | --group="docker" option to the docker daemon. HTH.
Hey Lokesh root:dockerroot does work as intended, there is also no longer a "docker" group like there used to be. For compatability with cockpit etc should something along these lines be re-included?
(In reply to Benjamin.au from comment #2) > Hey Lokesh > > root:dockerroot does work as intended, ugh sorry, my bad. It does. > there is also no longer a "docker" > group like there used to be. For compatability with cockpit etc should > something along these lines be re-included? The 'docker' group won't be included by default as allowing users in docker group to use docker without sudo is a security risk https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-January/msg00034.html . But of course, the group could be added manually after installation. Also see: https://github.com/docker/docker/blob/master/docs/sources/installation/fedora.md Also could you please comment on how exactly cockpit compatibility gets affected?
Yep that makes sense. Cockpit offers docker container configurations on the dashboards of non-root users, however it fails as the user does not have permission to use the socket (or something to that affect).
I see. Yup, for now you might need to get by with chown-ing /var/run/docker.sock to root:docker or appending '-G docker' to the OPTIONS variable in /etc/sysconfig/docker . I know it's annoying :| Closing this..
Why not leave docker group? If one wants to run a process to communicate with docker, he has to give that process necessary permissions. It's better to give group permission to socket than running as root. What is the point in removing the group?
Using the -G flag has no effect. The socket permissions are not changed after restarting the daemon. So you've broken the behavior of the docker command as specified in the documentation, and now admins are required to login to cockpit using the root account. How is that a security improvement? It seems to me that making major changes like this that alter upstream specifications should be tested extensively. Why is this marked as not a bug, when it brakes the documented behavior of the package?
Current Cockpit works just fine without a docker group. cockpit-bridge escalates privileges using sudo and/or pkexec and accesses before accessing the docker socket.
By "current", do you mean the package in the extras repo, or the latest release? Regardless, the -G flag no longer has any effect. Wouldn't it make more sense to preserve the documented upstream behavior, and just change the default run configuration to use "-G root"? Let the user decide. After all, this isn't Windows or Mac.
This bug is about Fedora, right? Cockpit in Fedora 22 (ie: 0.67-2) works fine without a docker group present. I haven't tested Fedora 21.
(In reply to David Jones from comment #9) > By "current", do you mean the package in the extras repo, or the latest > release? > > Regardless, the -G flag no longer has any effect. Wouldn't it make more > sense to preserve the documented upstream behavior, and just change the > default run configuration to use "-G root"? Let the user decide. After all, > this isn't Windows or Mac. Can you check if the 'docker' group exists on your machine? If it doesn't, please create it and retry. With '-G docker', if the group doesn't exist it will have /var/run/docker.sock owned by root:root, but if it does, it'll be owned by root:docker. Just verified this on fedora 21 with docker-io-1.8.2-2.gitcb216be.fc21