Bug 1119282 - [Regression] Unable to run docker client as non-root user
Summary: [Regression] Unable to run docker client as non-root user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: docker-io
Version: 19
Hardware: Unspecified
OS: Unspecified
urgent
unspecified
Target Milestone: ---
Assignee: Lokesh Mandvekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1121977 1124925 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-14 12:26 UTC by Pete Savage
Modified: 2015-09-03 08:31 UTC (History)
17 users (show)

Fixed In Version: systemd-204-20.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-22 03:30:31 UTC


Attachments (Terms of Use)

Description Pete Savage 2014-07-14 12:26:20 UTC
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


How reproducible:


Steps to Reproduce:
1. Run docker ps
2.
3.

Actual results:
2014/07/14 13:25:33 Get http:///var/run/docker.sock/v1.12/containers/json: dial unix /var/run/docker.sock: permission denied


Expected results:
Docker command should run

Additional info:

Comment 1 Marek Goldmann 2014-07-14 14:00:29 UTC
I'm seeing this too, this helps:

sudo chown root:docker /var/run/docker.sock

Comment 2 Marek Goldmann 2014-07-14 14:02:09 UTC
In my case the issue is with docker-io-1.0.0-6.fc20.x86_64 package.

Comment 3 Pete Savage 2014-07-14 15:56:53 UTC
Thanks Marek,

The workaround fixed it!

Comment 4 Phil 2014-07-14 16:27:53 UTC
docker-io changelog shows:

* Tue Jun 24 2014 Lokesh Mandvekar <lsm5@fedoraproject.org> - 1.0.0-4
- Set mode,user,group in docker.socket file

file /usr/lib/systemd/system/docker.socket:
SocketUser=root
SocketGroup=docker

On startup, this is what systemd tells us:

systemd[1]: [/usr/lib/systemd/system/docker.socket:7] Unknown lvalue 'SocketUser' in section 'Socket'
systemd[1]: [/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:
https://github.com/systemd/systemd/commit/3900e5fdff688dc3c273f177d9d913b7389d5561

Comment 5 Lokesh Mandvekar 2014-07-14 16:41:56 UTC
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

Comment 6 Phil 2014-07-14 17:51:15 UTC
Hi Lokesh,

SocketUser and SocketGroup came with systemd 214. F20 ships 208.

Let's see what happens next :)

Comment 7 Lokesh Mandvekar 2014-07-14 19:24:13 UTC
Zbigniew, could you please update systemd for f20, perhaps f19 too.

Comment 8 Lars Kellogg-Stedman 2014-07-18 00:58:37 UTC
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
    [Unit]
    Description=Docker Application Container Engine
    Documentation=http://docs.docker.io
    After=network.target

    [Service]
    Type=notify
    EnvironmentFile=-/etc/sysconfig/docker
    ExecStart=/usr/bin/docker -d --selinux-enabled --dns 172.17.42.1
    Restart=on-failure
    LimitNOFILE=1048576
    LimitNPROC=1048576

    [Install]
    WantedBy=multi-user.target
    EOF

    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
line option).

This change will persist after a reboot (unlike manually chmod'ing the
socket created by systemd).

Comment 9 Fedora Update System 2014-07-20 00:39:56 UTC
systemd-208-20.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-208-20.fc20

Comment 10 Fedora Update System 2014-07-21 05:21:58 UTC
Package systemd-208-20.fc20:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2014-8572/systemd-208-20.fc20
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2014-07-22 03:30:31 UTC
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.

Comment 12 Pete Savage 2014-07-22 13:23:05 UTC
Is there a way to get this fixed in fc19 too?

Comment 13 Lokesh Mandvekar 2014-07-22 14:18:47 UTC
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.

Comment 14 Lokesh Mandvekar 2014-07-22 14:19:15 UTC
s/Peter/Pete (sorry about that)

Comment 15 Zbigniew Jędrzejewski-Szmek 2014-07-22 14:54:05 UTC
It seems that the patch is easy to backport from F20 to F19, so I'll release a patched systemd-204 for F19 too.

Comment 16 Pete Savage 2014-07-22 15:06:53 UTC
Thanks

Comment 17 Lokesh Mandvekar 2014-07-22 15:09:14 UTC
(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 :)

Comment 18 Zbigniew Jędrzejewski-Szmek 2014-07-23 00:56:17 UTC
*** Bug 1121977 has been marked as a duplicate of this bug. ***

Comment 19 Fedora Update System 2014-07-23 03:55:17 UTC
systemd-204-20.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/systemd-204-20.fc19

Comment 20 Marek Goldmann 2014-07-31 10:29:36 UTC
*** Bug 1124925 has been marked as a duplicate of this bug. ***

Comment 21 Fedora Update System 2014-08-08 08:40:55 UTC
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.

Comment 22 hallajs 2015-07-13 14:17:06 UTC
This issue still persists on fc22, mind sharing if a fix would be deployed?

Comment 23 Lars Kellogg-Stedman 2015-07-31 13:44:50 UTC
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.

Comment 24 Yajo 2015-08-03 07:11:25 UTC
The same is true with `sudo`, and you don't need to create the `wheel` group.

Comment 25 Lars Kellogg-Stedman 2015-08-03 16:01:49 UTC
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.

Comment 26 Yajo 2015-08-04 10:06:41 UTC
New bug 1249986 opened.

Comment 27 Stef Walter 2015-09-03 08:31:24 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.