> Permission issues with bind mounts just totally disappear when you go rootless.

Recent kernel versions have gained uid mapping capabilities on mounts. Hopefully future docker will make use of it. Then we can run entire containers as different users.

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

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

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.

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

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.

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...

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

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

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.

I have a problem with mounting a named foo in a container (at /foo) and bindfsing the underlying directory of that volume on ${HOME}/foo with create-for parameters so that when the host user touch files in it they are owned by host 1000:1000 but inside the container it's owned by 33:33.

Volume foo really contains only a unix socket. This unix socket is shared between the host and the container for xdebug communication.

So, this doesn't work, the container process can't write/read the socket even though it can manipulate other files in the mounted volumes /foo and they appear as owned by 1000:1000 on the host and vice versa.

But if I mount the volume directly like that: ${HOME}/foo:/foo then it works and the container can write to the socket and the host and the container can communicate both ways.

Would rootless podman allow me to use a named volume ? Why doesn't it work like I think it should, is it because the unix socket lives in the kernel 'or something' ? Maybe it's a question for SO.

Oh, I tried running the process in the container under a different uid but it complained about unprivileged user. Going the other way may do it, thanks. Although it requires more fiddling with stock images.

If I create a file with certain permission bits in the container, I'd expect the file to be 100% identical when pulling it over to the host, but maybe that's just "legacy" thinking coming from my docker experience?

What about copying files directly between containers, would that change the permissions as well?

The permission bits are metadata on the fs, the file can still be identical.

Plus, how permissions on a file on the container be identical in the host, if e.g. the groups/users are different?

There’s also the ability for podman to run as a system service, and provide an OCI compatible container API. This then integrates seamlessly with the actual docker-compose.

See: https://www.redhat.com/sysadmin/podman-docker-compose

I do that!

It's 99.999% compatible as the podman people basicaly reimplemented all the docker daemon APIs.

It sometimes lags a bit behind, because sometime docker implements new stuff... But for usage with docker-compose it has worked flawlessly for me.

EDIT: you can also export the podman unix socket via socat, i also tried it to run a rootless docker runtime in kubernetes (podman daemon running as a pod, to run docker builds in kubernetes) as an experiment. It works but i'd love to see a better integration with Gitlab runner project.

Gitlab is supposedly getting podman support any time soon, in 15.1 IIRC ?

So like, you can use docker compose for podman instead of docker, instead of something like podman compose?

You have to point your $DOCKER_HOST to the podman unix socket or something, but other than that it’s the actual docker-compose experience. Via the env var trick you could even use the actual docker binary. But you could just alias docker to podman and it works the same, by design!