{"action":"created","issue":{"url":"https://api.github.com/repos/docker/docker/issues/11253","labels_url":"https://api.github.com/repos/docker/docker/issues/11253/labels{/name}","comments_url":"https://api.github.com/repos/docker/docker/issues/11253/comments","events_url":"https://api.github.com/repos/docker/docker/issues/11253/events","html_url":"https://github.com/docker/docker/pull/11253","id":60344823,"number":11253,"title":"Proposal: User namespace support for re-mapped root per daemon setting","user":{"login":"estesp","id":1397980,"avatar_url":"https://avatars.githubusercontent.com/u/1397980?v=3","gravatar_id":"","url":"https://api.github.com/users/estesp","html_url":"https://github.com/estesp","followers_url":"https://api.github.com/users/estesp/followers","following_url":"https://api.github.com/users/estesp/following{/other_user}","gists_url":"https://api.github.com/users/estesp/gists{/gist_id}","starred_url":"https://api.github.com/users/estesp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/estesp/subscriptions","organizations_url":"https://api.github.com/users/estesp/orgs","repos_url":"https://api.github.com/users/estesp/repos","events_url":"https://api.github.com/users/estesp/events{/privacy}","received_events_url":"https://api.github.com/users/estesp/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/docker/docker/labels/1-design-review","name":"1-design-review","color":"fef2c0"},{"url":"https://api.github.com/repos/docker/docker/labels/Proposal","name":"Proposal","color":"009800"},{"url":"https://api.github.com/repos/docker/docker/labels/UX","name":"UX","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-03-09T13:46:30Z","updated_at":"2015-03-17T23:45:17Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/docker/docker/pulls/11253","html_url":"https://github.com/docker/docker/pull/11253","diff_url":"https://github.com/docker/docker/pull/11253.diff","patch_url":"https://github.com/docker/docker/pull/11253.patch"},"body":"## Proposal for User Namespace Daemon Support\r\n\r\nThis is a docs-first proposal to get review/feedback on the UX for specifying a per-daemon-instance remapping of container root to an unprivileged user.\r\n\r\n### Depends on libcontainer API/userns support\r\n\r\nThe support for user namespaces already exists in **libcontainer**.  The PR for bringing that new API and functionality is open for review: #11208.  This present proposal cannot be implemented until that PR is merged and the libcontainer vendor is updated in Docker itself.\r\n\r\n### A per-daemon setting for root\r\n\r\nThe documentation change in this PR notes a new flag `-r, --root=\"\"` which would be used to specify the requester user & group name--or uid:gid--that the daemon would instantiate new containers as the remapped root.  Specifying a special value of `default` would be the user's request to have Docker create (or use if existing) a special user/group named `dockroot` (docker group is already taken and used by Docker itself).\r\n\r\nThis new flag, when specified, would cause a new template (see https://github.com/docker/docker/blob/master/daemon/execdriver/native/template/default_template.go for current template) to be used when containers are created with the **native** execdriver, which will cause the added creation of a user namespace, using the specified `uid:gid` as the remapped root within the container.\r\n\r\n### Other required modifications to support user namespaces\r\n\r\n#### Locally hosted layer content\r\nBecause the filesystem layers of any image have root:root ownership of most of the files, a re-mapping operation will also need to occur on untar and tar of image layers.  This is one of the reasons to start with user namespaces as a daemon-level option:  to keep from potentially significant churn of `chmod` activity, all image layers for a specific daemon can be untarred with root:root ownership mapped to the re-mapped unprivileged *container root* uid:gid, allowing those images to be used by any containers within the daemon successfully.  When images are pushed, since a `tar` action happens anyway, these image layers can be remapped back to root:root at this point.  This work is underway, but has no UX component for review.\r\n\r\n#### <a name=\"daemon-root\"></a>Daemon root\r\nCurrently the daemon, by default, creates a directory `/var/lib/docker` owned by `root:root` with permissions `0700`.  Given the actual container root filesytems live underneath this hierarchy, a user namespaced container will not even start today as the early `chdir()` call will fail due to lack of access to the root-accessible-only directory hierarchy under `/var/lib/docker`.\r\n\r\nMy proposal is that `/var/lib/docker` will become a super-root of any number of daemon roots, each one owned by the `uid:gid` of the daemon's remapped root, if provided.  If root is **not** remapped (user namespaces are \"off\"), then a new daemon root under `/var/lib/docker` (or the user-specified location) simply named \"0.0\" will be used.  For migration purposes, the first time the daemon is run with this feature, current data from `/var/lib/docker` (or the user-specified root) will be migrated to the subdir `./0.0` (for the user namespaces-off case).  The \"super-root\" directory perms would change to `0755`, but subdirectories would still use `0700`, with ownership matching the remapped root, or real root depending on the case.  An example of three subdirectories under a `/var/lib/docker` with `0755` permissions is shown below:\r\n```\r\ndrwx------ 2 2000 2000 4096 Mar 13 13:34 2000.2000\r\ndrwx------ 2  500  500 4096 Mar 13 13:34 500.500\r\ndrwx------ 2 root root 4096 Mar 13 13:34 0.0\r\n```\r\n\r\n## Questions\r\n\r\nOpen questions/concerns from early review/discussion\r\n\r\n### Is this a bad starting point if we support full specification of user/group maps in the future?\r\n\r\nI believe that if we support (in the future) more complete user control over the namespace capabilities that exist in libcontainer/Linux kernel level, it will not deprecate this \"mode\" of user namespace support.  I believe instead it will be a \"Conflicts:\" scenario between `--root` and `{future map config option(s)}`.  Because we expect `--root` can be supported by the daemon and image/graph subsystem, it will probably be the more likely path, and the custom uid/gid maps will need to have a set of restrictions around using Hub images, or other \"migration\" scenarios.\r\n\r\n### How does this impact the use of `--privileged`?\r\n\r\nGiven user namespaces are about restricting privileges inside the container, you can guess that the general answer is \"--privileged is incompatible with user namespaces\".  However, given using `--privileged` maps to a varied set of actions at container setup (from making `/sys` *rw* instead of just *r* to allowing more `CAPS_` to remain), it will require a deeper look at which of those may be compatible or reasonable with user namespacing restrictions.\r\n \r\n"},"comment":{"url":"https://api.github.com/repos/docker/docker/issues/comments/82643492","html_url":"https://github.com/docker/docker/pull/11253#issuecomment-82643492","issue_url":"https://api.github.com/repos/docker/docker/issues/11253","id":82643492,"user":{"login":"tphyahoo","id":1337,"avatar_url":"https://avatars.githubusercontent.com/u/1337?v=3","gravatar_id":"","url":"https://api.github.com/users/tphyahoo","html_url":"https://github.com/tphyahoo","followers_url":"https://api.github.com/users/tphyahoo/followers","following_url":"https://api.github.com/users/tphyahoo/following{/other_user}","gists_url":"https://api.github.com/users/tphyahoo/gists{/gist_id}","starred_url":"https://api.github.com/users/tphyahoo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tphyahoo/subscriptions","organizations_url":"https://api.github.com/users/tphyahoo/orgs","repos_url":"https://api.github.com/users/tphyahoo/repos","events_url":"https://api.github.com/users/tphyahoo/events{/privacy}","received_events_url":"https://api.github.com/users/tphyahoo/received_events","type":"User","site_admin":false},"created_at":"2015-03-17T23:45:17Z","updated_at":"2015-03-17T23:45:17Z","body":"Could this have label project/security added?"}}