{"action":"created","issue":{"url":"https://api.github.com/repos/sclorg/rhscl2dockerfile/issues/18","labels_url":"https://api.github.com/repos/sclorg/rhscl2dockerfile/issues/18/labels{/name}","comments_url":"https://api.github.com/repos/sclorg/rhscl2dockerfile/issues/18/comments","events_url":"https://api.github.com/repos/sclorg/rhscl2dockerfile/issues/18/events","html_url":"https://github.com/sclorg/rhscl2dockerfile/issues/18","id":78034741,"number":18,"title":"Allow to run docker images as arbitrary user","user":{"login":"hhorak","id":1405588,"avatar_url":"https://avatars.githubusercontent.com/u/1405588?v=3","gravatar_id":"","url":"https://api.github.com/users/hhorak","html_url":"https://github.com/hhorak","followers_url":"https://api.github.com/users/hhorak/followers","following_url":"https://api.github.com/users/hhorak/following{/other_user}","gists_url":"https://api.github.com/users/hhorak/gists{/gist_id}","starred_url":"https://api.github.com/users/hhorak/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hhorak/subscriptions","organizations_url":"https://api.github.com/users/hhorak/orgs","repos_url":"https://api.github.com/users/hhorak/repos","events_url":"https://api.github.com/users/hhorak/events{/privacy}","received_events_url":"https://api.github.com/users/hhorak/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-05-19T10:43:39Z","updated_at":"2015-05-19T14:12:39Z","closed_at":null,"body":"This is a controversial requirement, that already got into some of the OpenShift docker images, but I've still missed the use cases why this is necessary in the docker images..\r\n\r\nFirst valid point is that no docker image should run as `root`, which seems to be something most people agree on IMHO. This may be achieved in daemon images like databases by using user `mysql` or `postgres` that is already created during RPM install in the Dockerfile (`USER mysql`).\r\n\r\nIn docker images that don't have such a user (ruby, python, nodejs) we probably need to create such a user explicitly in the Dockerfile. The current practice is to call it `default` and use `UID` 1000 or 1001 (where 1000 has better chance to hit the `UID` of user on the host, but otherwise both cases are almost the same).\r\n\r\n`docker run -u $(id -u) ...` allows to run the image as arbitrary user already, but what is missing in the image is mapping the `EUID` in the image to the entry in the image's `/etc/passwd` -- is this the issue OpenShift wants to address by features like this https://github.com/openshift/postgresql/commit/1916d06fab2f4e04c7511beaa17c7d6480a0d4d3 ?\r\n\r\nAFAICT, this should work nicely in docker in the future, so the above implementation is a temporary solution, right?\r\n\r\nThere were also ideas that the feature to run the image as arbitrary user has some security benefit, but given we still need to have some non-root user set in the Dockerfile everytime (because it is the only way to ensure `docker exec CONT /bin/sh` is not run as `root`), I don't see how this helps the security. Can somebody elaborate on this?\r\n\r\nThere is also one important block with the implementation mentioned above -- nss_wrapper is not part of the RHEL so far and we cannot install random packages into RHSCL docker images..\r\n\r\n@bparees @mfojtik @mnagy"},"comment":{"url":"https://api.github.com/repos/sclorg/rhscl2dockerfile/issues/comments/103513745","html_url":"https://github.com/sclorg/rhscl2dockerfile/issues/18#issuecomment-103513745","issue_url":"https://api.github.com/repos/sclorg/rhscl2dockerfile/issues/18","id":103513745,"user":{"login":"hhorak","id":1405588,"avatar_url":"https://avatars.githubusercontent.com/u/1405588?v=3","gravatar_id":"","url":"https://api.github.com/users/hhorak","html_url":"https://github.com/hhorak","followers_url":"https://api.github.com/users/hhorak/followers","following_url":"https://api.github.com/users/hhorak/following{/other_user}","gists_url":"https://api.github.com/users/hhorak/gists{/gist_id}","starred_url":"https://api.github.com/users/hhorak/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hhorak/subscriptions","organizations_url":"https://api.github.com/users/hhorak/orgs","repos_url":"https://api.github.com/users/hhorak/repos","events_url":"https://api.github.com/users/hhorak/events{/privacy}","received_events_url":"https://api.github.com/users/hhorak/received_events","type":"User","site_admin":false},"created_at":"2015-05-19T14:12:39Z","updated_at":"2015-05-19T14:12:39Z","body":"@csrwng wrote:\r\n> The approach so far is that in order to make something writeable inside an image we make it world-writable. In a normal system this would be horribly insecure. However, for a container I would say that this is acceptable given that it's contained.\r\n\r\n@rhatdan Dan, I remember you talking about containers that they actually don't contain -- what do you think about the above -- making some files world-writable in the container?\r\n\r\nAs I understand it, we are speaking only about one directory to be world-writable, right? In case of mysql that would be `/var/lib/mysql/data` that is mounted from host. But the directory we mount on the host will be also world-writable, which is a security hole rather than improvement."}}