Rootless podman - access to volume (host directory mount) owned by different user
Hi, I have a shared directory "test" owned by "share" (and group "share"). "share" is also a real user id on the host system. All users that need access to this directory have been made members of the "share" group. This works fine on the host. Now I need to set up a rootless container that will run an application requiring read and write access to that directory as well. That rootless container will be started by several users on the host (well, on multiple hosts really, but that's not relevant to this particular issue - I'm currently testing on a single host). I have tried countless variations but I can't make it work. My last attempt consists of setting up a container using this Dockerfile (simplified to only present the essence): FROM registry.fedoraproject.org/fedora:32 RUN groupadd -g 1000 user1 RUN groupadd -g 1001 shared RUN useradd -u1000 -g1000 -G1001 user1 RUN useradd -u1001 -g1001 shared USER user1 So two users are defined inside the container and their uids and gids match those of the host. "user1" is also made member of the "shared" group with the intention to make the shared directory accessible for "user1". That reflects the permissions as on the host. Running ls on the directory inside the container results in this output: $ podman run -it --net=host -v ./test:/home/test:z --userns=host localhost/test-img ls -ld /home/test drwxrwx---. 2 root nobody 4096 Feb 8 18:12 /home/test Outside of the container this directory has the following ownerships: $ ls -ld test/ drwxrwx---. 2 user1 share 4096 8 feb 19:12 test/ So some uid and gid remapping is going on and with ownership of root:nobody, my container user can't access the test directory. I would want the directory to have the same ownership inside the container, but I don't know how to get there. I thought the "--userns=host" option was for that purpose. but it still remaps the user and group for directory test. I have also tried "--userns=keep-id", but that makes no difference. Note that if I log in to the host as user "share" and run the container (changing the default container user to "share" as well), the /home/test directory is accessible inside the container. How can I prevent podman from remapping the ownership of that mounted volume or if that's not possible what is the proper way to provide shared access to a mounted volume to a different user ? Thank you, Geert P.S. For completeness, this experiment is with a simple local directory. In the final setup that "test" directory would have to be replaced with a locally mounted nfs share. I did somer experiments already and I can access nfs shares, but the same owner and group remapping prevent me from accessing that nfs share when running the container rootless from a user that's not the owner of that share. I hope the solution to my experiment will also fix it for an nfs share.
Hello Geert, when you start a rootless podman container, the root user inside the container will be mapped to your user on the host. As all host users are member of the "share" group, maybe you could just keep using root inside the container? Set a sticky group ID for the shared volume, so that all created files are automatically owned by the "share" group. cheers, Roland --- IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
Hi Roland, That is exactly my plan. I don't really mind the container user to become root and I could use "--userns=keep-id" if I want to avoid that. However that's not the issue I think. Regardless of what option I set the group is not right inside the container. It's mapped to "nobody" instead of sticking "share". With group "nobody" the directory is not accessible from within the host by anyone except "user1" (either mapped to root or just as user1 if I use "--userns=keep-id"). Regards, Geert
On 2/9/21 06:04, geert@kobaltwit.be wrote:
Hi Roland,
That is exactly my plan. I don't really mind the container user to become root and I could use "--userns=keep-id" if I want to avoid that.
However that's not the issue I think. Regardless of what option I set the group is not right inside the container. It's mapped to "nobody" instead of sticking "share". With group "nobody" the directory is not accessible from within the host by anyone except "user1" (either mapped to root or just as user1 if I use "--userns=keep-id").
Regards,
Geert _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
If you are using crun as your OCI Runtime, you can set `--annotation run.oci.keep_original_groups=1` and all groups owned by the rootless user will be allowed to access content from within the container. ``` man podman run ... Note: if the user only has access rights via a group, accessing the de‐ vice from inside a rootless container will fail. The crun(1) runtime offers a workaround for this by adding the option --annotation run.oci.keep_original_groups=1. ```
Ah, that works. Thanks! One follow-up question: with the annotation set I can access the directory even though the group is still named "nobody". That's a bit confusing. Is there a way to display the real gid as well ?
On 2/9/21 8:19 AM, geert@kobaltwit.be wrote:
Ah, that works. Thanks!
One follow-up question: with the annotation set I can access the directory even though the group is still named "nobody". That's a bit confusing. Is there a way to display the real gid as well ?
I believe the only way around that would be to use --gidmap or --subgitname [podman run] flags with a 1-gid wide "map". For example, `--gidmap=1001:$(id -g shared):1` so the host's "shared" GID is mapped to the GID 1001 (from your Dockerfile). -- Chris Evich, RHCA III Senior Quality Assurance Engineer If it ain't broke, yain't tryin' hard nough.
On 2/9/21 09:43, Chris Evich wrote:
On 2/9/21 8:19 AM, geert@kobaltwit.be wrote:
Ah, that works. Thanks!
One follow-up question: with the annotation set I can access the directory even though the group is still named "nobody". That's a bit confusing. Is there a way to display the real gid as well ?
I believe the only way around that would be to use --gidmap or --subgitname [podman run] flags with a 1-gid wide "map". For example, `--gidmap=1001:$(id -g shared):1` so the host's "shared" GID is mapped to the GID 1001 (from your Dockerfile).
Yes the issue is that the group is not mapped into the current user namespace, so the kernel reports it as `nobody`. Their is little we can do about it.
Op dinsdag 9 februari 2021 21:56:02 CET schreef Daniel Walsh:
On 2/9/21 09:43, Chris Evich wrote:
On 2/9/21 8:19 AM, geert@kobaltwit.be wrote:
Ah, that works. Thanks!
One follow-up question: with the annotation set I can access the directory even though the group is still named "nobody". That's a bit confusing. Is there a way to display the real gid as well ?
I believe the only way around that would be to use --gidmap or --subgitname [podman run] flags with a 1-gid wide "map". For example, `--gidmap=1001:$(id -g shared):1` so the host's "shared" GID is mapped to the GID 1001 (from your Dockerfile).
Yes the issue is that the group is not mapped into the current user namespace, so the kernel reports it as `nobody`. Their is little we can do about it.
Thanks for the replies, I can live with the nobody group as long as permissions are correct.
participants (5)
-
Chris Evich -
Daniel Walsh -
Geert Janssens -
geert@kobaltwit.be -
Roland Weber