3 ms·

> Do not use a UID below 10,000 I see the point but this kinda looks like extreme paranoia. I actually advise developers that are not so strong at docker and

by znpy 6y ago

> Do not use a UID below 10,000 I see the point but this kinda looks like extreme paranoia. I actually advise developers that are not so strong at docker and containers to use his 1000 in their container. Such uid is usually the default first uid in Ubuntu and thus makes running containers in their development machine easier (since now they don't have to deal with file permissions and uids without a corresponding user on their system). Someone will boo this and maybe even downvote, but it really helps developer "think operationally", and gets their dev environment closer to prod.

toolslive 6y ago
it's not bad advice to use UID 1000, BUT if you're using docker both for development and continuous integration, you might run into problems because jenkins (or whatever you're using) might not run with UID 1000. At that point, you're gonna to need to change your strategy and properly map the user/group outside the container to the user/group inside the container anyway.
kortex 6y ago
Right. This is great if you are still learning the ropes. However the title is best practices. Using uid 1000 and using rw file mounts exposes your main user to potential exploits. Often 1000 is in the docker group for convenience. That allows an attacker to potentially append some nasty code outside the container and get password-less sudo. Unlikely? Very. But security is all about layers. I've seen full-fat Ubuntu containers with uid 1000 which is in docker group on the host and ~ mounted to run some python flask app, in production.
- znpy 6y ago
  > I've seen full-fat Ubuntu containers with uid 1000 which is in docker group on the host and ~ mounted to run some python flask app, in production If you mount ~ in your containers you have bigger problems than uid 1000.
- wwright 6y ago
  Running with uid 1000 in the Docker group in prod is a very bad idea to begin with
  - Spivak 6y ago
    On your single-user dev laptop it’s very likely that you are user 1000 and probably put yourself in the docker group so you wouldn’t have to sudo to run docker ps. So then running your containers as that UID without user namespacing (docker’s default) opens you up to more attack surface than if it was uid 1001.
dotancohen 6y ago
So what is the right way to configure Docker such that both the container and my host user can alter files in the volume?
- kortex 6y ago
  Hoping to get a good answer via Cunningham's law here: the way I currently do it is to create a shared GID on the host, add the docker user to that same number GID (via build args), and chmod it appropriately. chmod -R 2775 on folder to be shared seems to do the trick. This is probably wrong and lazy. I think the rigorous approach is to use namespaces https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-remap/ https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-rem...
- pvtmert 6y ago
  docker daemon has a id remap option called userns-remap https://www.objectif-libre.com/en/blog/2020/06/30/securiser-docker-au-travers-de-la-fonctionnalite-userns-remap/ https://www.objectif-libre.com/en/blog/2020/06/30/securiser-...
  - cpuguy83 6y ago
    This is actually worse because the filesystem does not know about user namespaces.

by znpy 6y ago

toolslive 6y ago

it's not bad advice to use UID 1000, BUT if you're using docker both for development and continuous integration, you might run into problems because jenkins (or whatever you're using) might not run with UID 1000. At that point, you're gonna to need to change your strategy and properly map the user/group outside the container to the user/group inside the container anyway.

kortex 6y ago

Right. This is great if you are still learning the ropes. However the title is best practices. Using uid 1000 and using rw file mounts exposes your main user to potential exploits. Often 1000 is in the docker group for convenience. That allows an attacker to potentially append some nasty code outside the container and get password-less sudo. Unlikely? Very. But security is all about layers. I've seen full-fat Ubuntu containers with uid 1000 which is in docker group on the host and ~ mounted to run some python flask app, in production.

znpy 6y ago
> I've seen full-fat Ubuntu containers with uid 1000 which is in docker group on the host and ~ mounted to run some python flask app, in production If you mount ~ in your containers you have bigger problems than uid 1000.
wwright 6y ago
Running with uid 1000 in the Docker group in prod is a very bad idea to begin with
- Spivak 6y ago
  On your single-user dev laptop it’s very likely that you are user 1000 and probably put yourself in the docker group so you wouldn’t have to sudo to run docker ps. So then running your containers as that UID without user namespacing (docker’s default) opens you up to more attack surface than if it was uid 1001.

dotancohen 6y ago

So what is the right way to configure Docker such that both the container and my host user can alter files in the volume?

kortex 6y ago
Hoping to get a good answer via Cunningham's law here: the way I currently do it is to create a shared GID on the host, add the docker user to that same number GID (via build args), and chmod it appropriately. chmod -R 2775 on folder to be shared seems to do the trick. This is probably wrong and lazy. I think the rigorous approach is to use namespaces https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-remap/ https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-rem...
pvtmert 6y ago
docker daemon has a id remap option called userns-remap https://www.objectif-libre.com/en/blog/2020/06/30/securiser-docker-au-travers-de-la-fonctionnalite-userns-remap/ https://www.objectif-libre.com/en/blog/2020/06/30/securiser-...
- cpuguy83 6y ago
  This is actually worse because the filesystem does not know about user namespaces.