Rootful quadlet User and UIDMap overlay mount permission denied #24384
-
|
I wish to use rootful podman for networking, but the service needs to access bind mount for config and data. For a minimal example: where I take that this means that inside the container the service would be run as user 1000, and outside this is mapped to the same user. Similarly to when using rootless podman setting However starting the systemd unit fails with I think this is different from #9642 because they are trying to use the systemd.exec User= but here I think the generated quadlet still runs as root outside of the container? Is this way of using quadlet correct/supported? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 4 replies
-
|
TL;DR: You probably don't want UIDMap vs User
In your case you're using That's not an uncommon problem if the container is designed to start as root and switch to a non-root user when it begins. Images like that (say You're right that this concern shouldn't matter what image you use given your failure output, so in your case let's move on to UIDMapIf you're not familiar with the syntax you have said to take container UID 1000, and map that to the 1001th ID for the host user (running $ mkdir /tmp/example && chmod 777 /tmp/example
$ podman run --rm -itd --name test --uidmap 1000:1000 -v /tmp/example:/tmp/example:Z alpine
ERRO[0000] Unmounting /var/lib/containers/storage/overlay/ce4525d43a53464d1308cd59ce6c1ba9ef9bdd67054a9c1cdfa476fdd5ef7c71/merged: invalid argument
Error: mounting storage for container 9799d648e28cb1acaca4b88ccffca47a7212d6abbb1ecd4b03d5e0d63bfa2974: creating overlay mount to /var/lib/containers/storage/overlay/ce4525d43a53464d1308cd59ce6c1ba9ef9bdd67054a9c1cdfa476fdd5ef7c71/merged, mount_data="lowerdir=/var/lib/containers/storage/overlay/ce4525d43a53464d1308cd59ce6c1ba9ef9bdd67054a9c1cdfa476fdd5ef7c71/mapped/0/l/26CB7USPA5EZZVKE2JAXQYT56Y,upperdir=/var/lib/containers/storage/overlay/ce4525d43a53464d1308cd59ce6c1ba9ef9bdd67054a9c1cdfa476fdd5ef7c71/diff,workdir=/var/lib/containers/storage/overlay/ce4525d43a53464d1308cd59ce6c1ba9ef9bdd67054a9c1cdfa476fdd5ef7c71/work,nodev,metacopy=on,volatile,context=\"system_u:object_r:container_file_t:s0:c107,c445\"": permission deniedLooks like a SELinux issue in this case, although I seem to get that even with The error you get is not particularly helpful, but AFAIK it's about the need to always have a mapping entry for container root. On a rootless user you'd get this instead: # :Z for the volume here is for SELinux specifically, to avoid permission errors:
$ podman run --rm -it --uidmap '1000:1000' -v /tmp/example:/tmp/example:Z alpine
Error: container uses ID mappings ([]specs.LinuxIDMapping{specs.LinuxIDMapping{ContainerID:0x1, HostID:0x0, Size:0x1}}), but doesn't map UID 0Here's an example to illustrate mapping root in the container to host user ID 1000: # As root user on host:
$ echo hello > /tmp/example/from-host-root.txt
$ echo hello > /tmp/example/from-host-my-user.txt
$ chown 1000:1000 /tmp/example/from-host-my-user.txt
# Start a container with root container user mapped to host user 1000:
$ podman run --rm -itd --name test --uidmap 0:1000 -v /tmp/example:/tmp/example:Z alpine
$ podman exec -it test ash
# The results of our `--uidmap 0:1000` is here (container ID 0, to host ID 1000, single ID mapping range):
$ cat /proc/self/uid_map
0 1000 1
# Let's compare the ownership:
$ echo hello > /tmp/example/from-container-root.txt
$ stat -c '%U(%u):%G(%g) %n' /tmp/example/*
root(0):root(0) /tmp/example/from-container-root.txt
root(0):root(0) /tmp/example/from-host-my-user.txt
nobody(65534):nobody(65534) /tmp/example/from-host-root.txt
# Now on the host check ownership is set to UID 1000:
$ exit
$ stat -c '%U(%u):%G(%g) %n' /tmp/example/*
my-user(1000):my-user(1000) /tmp/example/from-container-root.txt
my-user(1000):my-user(1000) /tmp/example/from-host-my-user.txt
root(0):root(0) /tmp/example/from-host-root.txt
If we instead use # From within the container (this is redundant for rootful):
$ cat /proc/self/uid_map
0 0 1
1000 1000 1RootlessIn a rootless container the mapping rules are a bit different the 2nd UIDMap value is an offset from the user in # From the host:
$ cat /etc/subuid
my-user:524288:65536Here That may not seem as intuitive though due to that level of indirection, so Podman has this syntax for rootless mapping that allows you get the relative offset like This # No mapping for 1001 in /etc/subuid so it fails:
$ podman run --rm -it --uidmap '0:@1000' --uidmap '1:@1001' alpine
Error: parent ID UID 1001 is not mapped/delegated
# Next valid mapping for our my-user mappings:
$ podman run --rm -it --uidmap '0:@524288' alpine
$ cat /proc/self/uid_map
0 1 1Often you only need to map a specific container user to a host UID, in Quadlets for root this is While you're not focused on rootless, I hope that makes it a bit more clearer about what's going on and clarifies the difference between rootful and rootless usage. SolutionOk, so you probably don't need |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I know where my misunderstanding is... I thought podman always create a unique user namespace even when running rootful.. because the doc says
but apparantly when running as root every uid is mapped "as is". What I wanted to achieve is to use the same normal user in and outside of the container as is but prevent root inside the container to act as root outside. This can be achieved by ...This is probably too complicated so please correct me if this doesn't actually add any, if at all, security. |
Beta Was this translation helpful? Give feedback.
-
|
A container root is generally not equivalent to root on the host as capabilities are far less. You can use a non-root user if that works for you but it seems rather redundant to map a container ID of 1000 to a host ID of 1000 when that wouldn't change anything? I showed with commands to reproduce how the ownership is mapped both from the container and outside it. If you don't want to map between different container vs host ID you don't need the mapping? Otherwise just
Other than that doesn't matter much IIRC even non-root users have been able to escape containers in the past depending on context. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it came up that way because when using rootless podman I always use UserNS=keep-id (which is about the same as UIDMap=1000:1000) and User=1000. |
Beta Was this translation helpful? Give feedback.
-
Not quite, here's a brief overview of differences with a larger example to demonstrate:
You cannot use the two together explicitly. Rootless example for
|
Beta Was this translation helpful? Give feedback.
-
|
Regarding the original problem described in #24384 (comment) It works when I add an addtional
|
Beta Was this translation helpful? Give feedback.
-
Yes as my answer mentioned, root user needs to be mapped to something. But |
Beta Was this translation helpful? Give feedback.
A container root is generally not equivalent to root on the host as capabilities are far less. You can use a non-root user if that works for you but it seems rather redundant to map a container ID of 1000 to a host ID of 1000 when that wouldn't change anything?
I showed with commands to reproduce how the ownership is mapped both from the container and outside it. If you don't want to map between different container vs host ID you don't need the mapping?
Otherwise just
UIDMap=0:1000orUser=1000, but not both should work for you?