I’m in the process of setting up a development environment for a web development project. The host system is Fedora 35 with podman, for the container I use a Debian image.
The source code (PHP) is stored on my users home directory of the host system. When starting the container I mount it to /var/www/html like this:
podman run -d --name nc -p 8080:80 -v /home/bjoern/Repos/project:/var/www/html:Z project;
The problem: the source from the host is mounted as root:root to /var/ww/html while Apache runs as www-data on Debian which prevents Apache from writing to the webroot.
While it looks like the right tool, I struggle to understand this command:
podman unshare chown user:user $PATH
Maybe it is also the wrong approach. My expectation was that I can change this way the owner/group inside the container but what it actually does is changing the permissions on the host system which completely messed up my home directory. Basically it does the same as a plain “chown” so I don’t get the additional value of the “podman unshare” command.
Now, when the user runs the container, it is successful. The Postgresql process inside of the container runs as UID 26 inside of the container (and 100025 outside).
Inside the container, podman 0 mapped outside container as 3267 and bin group/1 (possibly also as root inside the container?). Then 26 inside the container mapped as 100025 outside the container and nobody group 65536 (possibly as regular user inside the container?).
Users on outside the container, from /etc/group has users:x:100:.
From that, means podman unshare chown ... change the UID inside the container that have been mapped to different UID outside the container. From this, the process happen inside the container should not mess up host userspace if mapped to non bin group but to nobody group(?). From /etc/group we can find nobody:x:65534:.
But of course, like I said above, I don’t understand about podman and any container things. All I said only from my understanding from reading that article.
I think inside the container the user is mapped as root to 1001, so still in the user namespace, so you would have to map the usable UID/GID into the 1000+n so 1033 say.