Hacker News Reader

Comment by taftster | Hacker News Reader

I'm surprised that the article doesn't mention the royal pain that is of the user id mappings required for execution of limited privilege containers. This is by far the biggest con and pain in the butt with using Podman.*

Though I acknowledge the problem, the user id mapping file is really unfortunate and basically non-portable between systems. I hope there has been better tooling built up around this lately, as Podman basically "wins" over Docker in my book, in all other ways. But the pain required to setup and properly manage user-privileged containers with Podman is just a bit too terse and becomes a significant barrier.

*[edit] to be fair, also a pain with rootless Docker too.

View on HN

I wrote a portable solution for the user ID mapping problem: https://github.com/FooBarWidget/matchhostfsowner

It's an init program — written in Rust — that changes the UID of an account (including home directory) inside the container to match that of the host. It takes care of corner cases such as what happens if there's a conflicting account, or when the user wants to run as root, or when chowning the home directory is too slow, etc.

In a related article I detail why such a program is non-trivial, what all the caveats are that one might have to look out for, and what alternative approaches exist (e.g. bind mounts): https://www.joyfulbikeshedding.com/blog/2021-03-15-docker-an...

I remember it used to be a thing to deal with, but in the last year installing Podman has been the only step I’ve needed to take. Well, and I use Fedora now, where it obviously works out of the box. I think it’s a solved problem at this point.

I wrote a mini tutorial (as a Reddit comment) about how to deal with UID/GID mappings when you run rootless podman and you want a specific container user to write to a bind-mounted directory:

https://www.reddit.com/r/podman/comments/103ut7z/comment/j31...

Short summary: My best tip is to see if either "--user $uid:$gid" or "--user 0:0" works together with this command:

podman run --rm --user $uid:$gid --volume ./dir:/dir:Z --userns keep-id:uid=$uid,gid=$gid IMAGE

(requires podman > 4.3.0)

The main architectural problem here (originating in Docker) is promoting the shared volume system in the first place. It's just the wrong thing to try in so many ways. It's insecure and runs are non-reproducible. And the OS integration is like a tragedy novel when you look at all the different platforms with unique problems on each. A much better way would be to support automatically copying inputs in and outputs out using the existing layer system.

(As an optimization you could it in a rsyncish way)

What's the issue? I find podman to be better in this exact scenario, specifically with bind mount permission shenanigans. Don't you just set up $USER to have a couple of thousand uidns once on your hosts? Is there any other friction I'm missing?

That is true. But I have to say that migrating my home server to using rootless Docker (which included all of the same pain), was a fantastic improvement when I finally got around to doing it. I could now migrate to Podman, but less motivated now, since rootless Docker works so nicely

I've not had any issues migrating containers between systems and setting up said systems in the past year when it came to this particular issue. I think this particular hurdle has been eliminated.

Reply on news.ycombinator.com