Description of problem: Docker used to be able to run it's client as non-root user, allowed things like `docker ps` and `docker run` but since latest update I am unable to do that. Even though the user running the docker command is in the docker group, which previously worked.
Version-Release number of selected component (if applicable):docker-io-1.0.0-6.fc19.x86_64
Steps to Reproduce:
1. Run docker ps
2014/07/14 13:25:33 Get http:///var/run/docker.sock/v1.12/containers/json: dial unix /var/run/docker.sock: permission denied
Docker command should run
I'm seeing this too, this helps:
sudo chown root:docker /var/run/docker.sock
In my case the issue is with docker-io-1.0.0-6.fc20.x86_64 package.
The workaround fixed it!
docker-io changelog shows:
* Tue Jun 24 2014 Lokesh Mandvekar <firstname.lastname@example.org> - 1.0.0-4
- Set mode,user,group in docker.socket file
On startup, this is what systemd tells us:
systemd: [/usr/lib/systemd/system/docker.socket:7] Unknown lvalue 'SocketUser' in section 'Socket'
systemd: [/usr/lib/systemd/system/docker.socket:8] Unknown lvalue 'SocketGroup' in section 'Socket'
Looks like Lokesh added a systemd feature that isn't available in F20 yet:
Hi Phil, the SocketUser and SocketGroup is Re: CVE-2014-3499 Bug 1114810 . Not certain yet if systemd for f20 has the relevant stuff http://koji.fedoraproject.org/koji/packageinfo?packageID=10477
SocketUser and SocketGroup came with systemd 214. F20 ships 208.
Let's see what happens next :)
Zbigniew, could you please update systemd for f20, perhaps f19 too.
Note that you can work around this issue in Fedora 20 like this:
systemctl stop docker.socket
systemctl disable docker.socket
systemctl disable docker
cat > /etc/systemd/system/docker.service <<EOF
Description=Docker Application Container Engine
ExecStart=/usr/bin/docker -d --selinux-enabled --dns 172.17.42.1
systemctl enable docker
systemctl start docker
This disable socket activation for docker, which means that systemd
is no longer responsible for creating the docker socket. The docker
daemon itself will create the socket, and will create it owned by the
"docker" group (or any other group you specify in the --group command
This change will persist after a reboot (unlike manually chmod'ing the
socket created by systemd).
systemd-208-20.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-208-20.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
systemd-208-20.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Is there a way to get this fixed in fc19 too?
Hi Peter, looks like the systemd folks only pushed it for f20, I could push the non-socket-activation version for f19 which would take care of this bug.
Also just fyi, f21 might be out soon (still few days to go I think), making f19 end-of-life.
s/Peter/Pete (sorry about that)
It seems that the patch is easy to backport from F20 to F19, so I'll release a patched systemd-204 for F19 too.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #15)
> It seems that the patch is easy to backport from F20 to F19, so I'll release
> a patched systemd-204 for F19 too.
coool, thanks so much :)
*** Bug 1121977 has been marked as a duplicate of this bug. ***
systemd-204-20.fc19 has been submitted as an update for Fedora 19.
*** Bug 1124925 has been marked as a duplicate of this bug. ***
systemd-204-20.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
This issue still persists on fc22, mind sharing if a fix would be deployed?
hallajs: it was an intentional configuration change that running "docker" requires root privileges, because having docker access effectively gives you root on the system. Because this is a security issue, the default configuration is unlikely to change.
If you don't have these particular concerns in your own environment, you can simply configure your system to have a `docker` group, make sure you're a member of that group, and make sure the `docker` daemon is configured to use that group when it creates the socket.
The same is true with `sudo`, and you don't need to create the `wheel` group.
Yajo: While true, that's because sudo's primary purpose is privilege escalation. That is *not* the primary purpose of Docker, and it is highly likely that the privilege-escalating aspects of Docker are not necessarily obvious to everyone using it.
Anyway, I was just stating my understanding of why the changes were made. If folks want to see a change in this behavior, it would probably be better to open a new bz for that specific request rather that continuing discussion on this one that was closed last year.
New bug 1249986 opened.
The difference between privilege escalation via sudo and that via docker is that the former is audited, logged, and uses a well known privilege escalation path.
Privilege escalation via the docker group (which is correctly not present by default) is not audited, cannot be logged, is wide open, does not respect SELinux contexts.
Even the upstream Docker project warns against this.