5 ms·

So what's the solution for 'root inside a docker container is root on the host'? We'd like to ship a set of utilities as a docker container, but unless the sys

So what's the solution for 'root inside a docker container is root on the host'? We'd like to ship a set of utilities as a docker container, but unless the sysadmin gives everyone 'sudo' privileges on the server (unlikely and insecure), they can't run the container and its utilities. Any advice?

shykes 13y ago
Look for an update on this in 0.9 :) Future versions of the Docker API will natively support scoping. This means that each API client will see a different subset of the Docker engine depending on the credentials and origin of the connection. This will be implemented in combination with introspection, which allows any container to open a connection to the Docker engine which started it. When you combine scoping and introspection, you get really cool scenarios. For example, let's say your utility is called "dockermeister". Each individual user could deploy his own copy of dockermeister, in a separate container. Each dockermeister container would in turn connect to Docker (via introspection), destroy all existing containers, and create 10 fresh redis containers (for reasons unknown). Because each dockermeister container is scoped, it can only remove containers that are its children (ie that were created from the same container at an earlier time). So they cannot affect each other. Likewise, the 10 new redis containers will only be visible to that particular user, and not pollute the namespace of the other users. Of course scoping works at arbitrary depth levels... so you could have containers starting containers starting containers. Containers all the way down :)
kapilvt 13y ago
user namespaces will solve this. lxc in ubuntu 14.04 already supports docker in user lxc, ie. no root needed. add silly disclaimer.. yes docker has some notion of portable containers plugins, but it uses lxc atm, and the feature is in lxc upstream.

shykes 13y ago

Look for an update on this in 0.9 :) Future versions of the Docker API will natively support scoping. This means that each API client will see a different subset of the Docker engine depending on the credentials and origin of the connection. This will be implemented in combination with introspection, which allows any container to open a connection to the Docker engine which started it. When you combine scoping and introspection, you get really cool scenarios. For example, let's say your utility is called "dockermeister". Each individual user could deploy his own copy of dockermeister, in a separate container. Each dockermeister container would in turn connect to Docker (via introspection), destroy all existing containers, and create 10 fresh redis containers (for reasons unknown). Because each dockermeister container is scoped, it can only remove containers that are its children (ie that were created from the same container at an earlier time). So they cannot affect each other. Likewise, the 10 new redis containers will only be visible to that particular user, and not pollute the namespace of the other users. Of course scoping works at arbitrary depth levels... so you could have containers starting containers starting containers. Containers all the way down :)

kapilvt 13y ago

user namespaces will solve this. lxc in ubuntu 14.04 already supports docker in user lxc, ie. no root needed. add silly disclaimer.. yes docker has some notion of portable containers plugins, but it uses lxc atm, and the feature is in lxc upstream.