New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running docker entirely as non-root (CONFIG_USER_NS) #1034

Closed
pwaller opened this Issue Jun 27, 2013 · 9 comments

Comments

Projects
None yet
7 participants
@pwaller
Contributor

pwaller commented Jun 27, 2013

Feature request.

As mentioned in #132, I raised the idea of running docker as non-root using the kernel CONFIG_USER_NS feature.

Any chance of this being possible eventually?

@unclejack

This comment has been minimized.

Show comment
Hide comment
@unclejack

unclejack Aug 2, 2013

Contributor

This isn't possible. The docker daemon needs to do a lot of things which really require root rights. Extracting layers which contain root owned files, setting up and deleting netfilter rules, mounting and unmounting layers via AUFS and other such things require root rights.

The docker client doesn't need any root permissions.

@creack I think you can close this issue.

Contributor

unclejack commented Aug 2, 2013

This isn't possible. The docker daemon needs to do a lot of things which really require root rights. Extracting layers which contain root owned files, setting up and deleting netfilter rules, mounting and unmounting layers via AUFS and other such things require root rights.

The docker client doesn't need any root permissions.

@creack I think you can close this issue.

@pwaller

This comment has been minimized.

Show comment
Hide comment
@pwaller

pwaller Aug 7, 2013

Contributor

@unclejack, I agree vis-a-vis netfilter rules, but my understanding is that with CONFIG_USER_NS a non-root user can have root permissions inside the container and therefore do things with mounts. If so, it could still be useful to make containers as a normal user even though they can't make network connections. Maybe you're right though.

Contributor

pwaller commented Aug 7, 2013

@unclejack, I agree vis-a-vis netfilter rules, but my understanding is that with CONFIG_USER_NS a non-root user can have root permissions inside the container and therefore do things with mounts. If so, it could still be useful to make containers as a normal user even though they can't make network connections. Maybe you're right though.

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Aug 7, 2013

Contributor

@pwaller: ultimately, it should be possible to run the docker daemon without root rights, and invoke appropriate tools with sudo. But for now, lxc-start still needs root privileges (it is a work in progress; see this post on Serge Hallyn's blog for details.

Contributor

jpetazzo commented Aug 7, 2013

@pwaller: ultimately, it should be possible to run the docker daemon without root rights, and invoke appropriate tools with sudo. But for now, lxc-start still needs root privileges (it is a work in progress; see this post on Serge Hallyn's blog for details.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Nov 27, 2013

Collaborator

These are actually 2 different requests here:

Request 1 is to allow running the docker daemon as non-root on the host system.

Request 2 is to allow running individual docker applications as non-root, but make them each think they have root privileges, thanks to the CONFIG_USER_NS.

I suggest opening 2 different issues (or finding an existing issue for each).

Collaborator

shykes commented Nov 27, 2013

These are actually 2 different requests here:

Request 1 is to allow running the docker daemon as non-root on the host system.

Request 2 is to allow running individual docker applications as non-root, but make them each think they have root privileges, thanks to the CONFIG_USER_NS.

I suggest opening 2 different issues (or finding an existing issue for each).

@pwaller

This comment has been minimized.

Show comment
Hide comment
@pwaller

pwaller Nov 27, 2013

Contributor

I had a cursory look, couldn't find anything, so created two issues (I'd rather the ideas didn't get totally lost). Apologies in advance for the additional mess if they are dupes.

Contributor

pwaller commented Nov 27, 2013

I had a cursory look, couldn't find anything, so created two issues (I'd rather the ideas didn't get totally lost). Apologies in advance for the additional mess if they are dupes.

@sebastian-luna-valero

This comment has been minimized.

Show comment
Hide comment
@sebastian-luna-valero

sebastian-luna-valero Apr 3, 2014

@unclejack Many thanks for your clarification: "The docker client doesn't need any root permissions."

Sorry, a newbie asking here: by "docker client" do you mean the ones listed here?
http://docs.docker.io/en/latest/reference/api/remote_api_client_libraries/

I have already setup my Dockerfile and pushed the resulting image to the Index, so it is now possible to run our code by doing:

docker pull myuser/myrepo
docker run myuser/myrepo comand arg1 arg2 arg3

However, we can not ask anyone out there to have a root permissions in their ends to run our code. That is why I would like to know how to use the "docker client". Could you please help?

Many thanks in advance for your time!

sebastian-luna-valero commented Apr 3, 2014

@unclejack Many thanks for your clarification: "The docker client doesn't need any root permissions."

Sorry, a newbie asking here: by "docker client" do you mean the ones listed here?
http://docs.docker.io/en/latest/reference/api/remote_api_client_libraries/

I have already setup my Dockerfile and pushed the resulting image to the Index, so it is now possible to run our code by doing:

docker pull myuser/myrepo
docker run myuser/myrepo comand arg1 arg2 arg3

However, we can not ask anyone out there to have a root permissions in their ends to run our code. That is why I would like to know how to use the "docker client". Could you please help?

Many thanks in advance for your time!

@tphyahoo

This comment has been minimized.

Show comment
Hide comment
@tphyahoo

tphyahoo Mar 17, 2015

Shouldn't this have label project/security added? (I would do myself but I think only project admins can add labels.)

tphyahoo commented Mar 17, 2015

Shouldn't this have label project/security added? (I would do myself but I think only project admins can add labels.)

@bdharrington7

This comment has been minimized.

Show comment
Hide comment
@bdharrington7

bdharrington7 Jul 20, 2017

Hi, @pwaller @jpetazzo, has anything come out of this? Running Docker 17.03.01-ce-mac12 still requires the daemon to run as root. I read the blog post, and at the time (c. Oct. 2014) the author was saying that the functionality in lxc was already upstream, but the trail goes cold after that.

bdharrington7 commented Jul 20, 2017

Hi, @pwaller @jpetazzo, has anything come out of this? Running Docker 17.03.01-ce-mac12 still requires the daemon to run as root. I read the blog post, and at the time (c. Oct. 2014) the author was saying that the functionality in lxc was already upstream, but the trail goes cold after that.

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Aug 22, 2017

Contributor

@bdharrington7 sorry for the slow reply!

The daemon still requires to run as root. I don't know how hard it would be to lift that requirement, however you can run it as non-root (did I just contradict myself?!?) ... by running it through Docker-in-Docker, when the top-level Docker (the one running straight on the host) has user namespaces enabled. This will squash the UID of the inner Docker to a non-privileged UID, while still allowing the required network and filesystem operations to happen. It is contrived and probably not optimal for your usecase, but perhaps it can be a good starting point.

Contributor

jpetazzo commented Aug 22, 2017

@bdharrington7 sorry for the slow reply!

The daemon still requires to run as root. I don't know how hard it would be to lift that requirement, however you can run it as non-root (did I just contradict myself?!?) ... by running it through Docker-in-Docker, when the top-level Docker (the one running straight on the host) has user namespaces enabled. This will squash the UID of the inner Docker to a non-privileged UID, while still allowing the required network and filesystem operations to happen. It is contrived and probably not optimal for your usecase, but perhaps it can be a good starting point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment