Hacker News Reader

Comment by teekert | Hacker News Reader

Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now. It is so super annoying to download something with nzbget for example and then having to go through sudo to get to your downloaded files. It is indeed my major gripe with my docker compose setup atm.

Or just messing with a html file in the nginx docker bind mount, ugh!

If podman solves that I’m going all in tomorrow.

View on HN

> Are you saying that all files from your containers are owned by you as user? If so I will start investigating right now

You can do this with Docker today without much fuss.

Here's a bunch of web app examples (Flask, Rails, Django, Node, Phoenix) that run your containers as a non-root user which ensures any volume mounted files end up being set to your Docker host's user along with running your main process as a non-root user: https://github.com/nickjj?tab=repositories&q=docker-*-exampl...

There's no hard coding of user names either. The user name created in the Docker image never directly gets mapped back to your Docker host.

This works because bind mounts happen over uid:gid 1000:1000 by default, so as long as your Docker host user's uid:gid is 1000:1000 everything works out of the box. On Windows and macOS you don't need to even think about this because Docker Desktop will fix permissions for you and on native Linux chances are your user uid:gid is 1000:1000 because it's the first non-root user on your system. For non-controllable environments like CI you'd typically disable volumes which is a good idea anyways because you're probably not using volumes in production. For single server deploys on a self managed VPS you control the environment. I covered this in a little more detail in my DockerCon talk at: https://nickjanetakis.com/blog/best-practices-around-product...

In the worst case scenario where you have no other options you can make the Dockerfile more complicated and introduce build args for the uid:gid so you can change it to satisfy the needs of a specific host but I don't like this since you'd need to rebuild a different image for a different environment, but it would technically work. I've never run into this scenario after having used Docker since 2014. I've also done contract work for dozens of companies in all sorts of different environments.

That's fair, but that issue is more common than you think. Some folks use Linux desktop systems with multiple users: shared computers (family or university--not all lab environments have sane workstation user management, unfortunately), or a personal computer with multiple accounts for separation (e.g. a home and work user) both come to mind.

And sure, UID remapping is available, but that's no longer in the realm of "just works".

You can perform the step in my last paragraph to make it work in those cases. It would come down to introducing 2 new build args, making sure the user you create sets the uid:gid based on these values, defaulting to 1000:1000 so it works for most but allows you to override them by modifying 2 env variables in an .env file (you can configure docker-compose to set the build args with env vars).

If someone has a case where they are doing anything you described the above steps can be implemented in like 5 lines of code and 5 minutes. I didn't add it to my example apps because there's only been 1 or 2 requests for it over multiple years and I've never encountered it once, no one taking my Docker courses has ever hit a road block by it either.

The --uidmap and --gidmap options can map your regular user on the host to any specific user inside the container.

These options may look to be a bit complicated to use, but as soon as you understand how rootless Podman maps UIDs and GIDs it will be pretty straight forward.

I wrote two troubleshooting tips about how to use them:

https://github.com/containers/podman/blob/main/troubleshooti...

Root inside the container is the same as your user.

No it’s not. File written from inside the container into a mounted volume as root will be owned by root outside the container (uid 0, to be specific; doesn’t matter what the user is named).

Edit: I might have misunderstood parent, who might be referring to Podman attempting to manage the uid mapping.

Last thing I remember you can tweak your /etc/setuid, setgid to properly map between the user inside the container and outside

The parent comment is still talking about rootless podman (and really just user namespaces). Root in the container is absolutely mapped to the user executing podman outside the container.

If it mapped to root outside the container, you could just use podman to create setuid scripts owned by root for very trivial privelege escalation.

Yes I think you are right --- I was mistaken. Docker without the rootless operate in the way I described.

Something that can't be solved by PUID/PGID in the command or in Compose?

Reply on news.ycombinator.com