Rootful podman ubi8 keep-id basename

[th-hummel]

Hello,

using podman-5.2.5 on Fedora 41 x86_64, when I run an ubi8 container with --userns=keep-id option as root (for the sake of it I have no real need to do so), it prints the following error message:

# podman run -it --rm --userns=keep-id ubi8:latest /bin/bash
basename: missing operand
Try 'basename --help' for more information.

This happens whether or not root or containers have subuids/subgids

There is no error with host namespace

# podman run -it --rm --userns=host ubi8:latest /bin/bash
[root@b48e6c5e4783 /]# 

As a more general question, my understanding was that for such cases as --userns=nomap or keep-id or auto for rootless users, 2 nested usernamespaces were required/created (as shown by lsns -t user -T) to get the correct mapping.
This seems logical to me after some thought.

keep-id with rootful though seems to create only one usernamespace (againg shown with lsns), which seems logical at first too, but I don't understand how it can write the mapping 0 0 0 4294967295 inside without root having any subuids in the parent (global) usernamespace, nor why permission to follow the /proc/$$/ns/user symlink is denied (I can do that in other modes/usecases) ?
Or maybe I'm wrong and it stays in the global usernamespace

Thanks for your help

--
Thomas HUMMEL

[nalind]

The error is coming from the /etc/profile.d/which2.sh shell snippet, which is trying to determine exactly which shell it's running under by reading what the shell process is using as an interpreter using basename $(readlink /proc/$$/exe). /proc/1/exe is not readable, so readlink is returning an empty string.

[th-hummel]

Thanks for your answer. I see.

I don't understand why /proc/$$/exe or as I stated ns symlinks are not readable in such a case (see my questions above namespace handling above).

--
Thomas HUMMEL

[nalind]

I believe that's a mitigation for CVE-2019-5736.

[th-hummel]

Oh I see.

Still remains the question of how can uid_maps map be written as described previoulsy without subuids in the parent namespace (if I'm right thinking there's a child namespace in my case).

Thanks again

[nalind]

The /etc/subuid and /etc/subgid files, and their equivalents, are consumed by the newuidmap and newgidmap helpers, which use those contents to limit which mappings they'll write on behalf of a caller, but the kernel doesn't require that if the process writing to the maps has sufficient privileges, per user_namespaces(7).
You can confirm whether or not you're in the same user namespace using readlink or ls -l on /proc/self/ns/user.

[th-hummel]

Oh ok.

But podman seems to somehow rely on newuidmap (at least for some use) as it requires a rootless user has enough subuids (listed in /etc/subuid) to accomodate the ones in the image and even requires 'containers' subuids for rootful. Hence my confusion on why he could not require them in some other cases.

I know about the /proc//ns/user link but as you confirmed above, in this particular case, it was not permitted to read it. So I was sort of blind for that matter (I could user --privileged but I was unsure if it modified usernamespace creation or not)

Finally, can you confirm or infim my understanding that in a rootless case settings like --userns=nomap and the like cause 2 nested usernamespaces (the outter one where user is mapped as root and the inner one implementing wanted mapping (mapping described by the userns option value) ?
Apart directly writing the target mapping in only one usernamespace, using such an indirection (an intermediate usernamespace) is the only way I can think of succeeding in reaching such target mappings.

I find it somehow useful to understand what's going on underneath podman to actually understand how to fully use its options in a reasonable way.
Thanks again.

[rhatdan]

Podman attempts to join a user namespace via newuidmap and newgidmap by reading those files and finding the range, If it does not find a range it just creates a user namespace with it's UID mapped to Root in the usernamespace. And will fail if it attempts to do anything with a separate UID, for example podman pull of an image with more then one UID.

[th-hummel]

Thanks all for your answers.
Wrapping up all the info : the root cause of my misunderstanding was indeed that I was wrongfully assuming that subuids/subgids etc files had always to be checked, which is only the case when using newuidmap tool.

Still in a rootful container

podman run -it --rm -v /tmp:/tmp --userns=keep-id ubi8:latest /bin/bash

I can see indeed a usernamespace (as expected)
and the same mapping (0 0 -1) so all range of uids and I'm able to chwon to 1:1 for instance a file created inside /tmp. So I don't understand why you say "And will fail if it attempts to do anything with a separate UID"

Finally, I don't understand why I cannot follow the /proc/1/ns/user symlink but I can in a subshell inside the container.

Thanks for your help

[th-hummel]

Hello,
this makes sense but let's take the following sequence:

root@laptop:/home/hummel# id
uid=0(root) gid=0(root) groups=0(root)
root@laptop:/home/hummel# cat /etc/subuid /etc/subgid
hummel:100000:65536
hummel:100000:65536
root@laptop:/home/hummel# podman run -it --rm --userns=keep-id ubi8:latest /bin/bash 
basename: missing operand
Try 'basename --help' for more information.
[root@d5cb3c1c0aba /]# cat /proc/$$/uid_map 
         0          0 4294967295
[root@d5cb3c1c0aba /]# 

And in another shell

# lsns -t user -T
NS           TYPE  NPROCS   PID USER   COMMAND
4026531837   user     434     1 root   /usr/lib/systemd/systemd --switched-root 
├─4026533340 user       1  2737 root   /usr/sbin/irqbalance
├─4026533343 user       1  2762 root   /usr/libexec/upowerd
├─4026533344 user       1 10041 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533346 user       1 10431 root   /bin/bash
├─4026533454 user       1  3002 colord /usr/libexec/colord
├─4026533461 user       1  9995 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533535 user       1  8214 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533539 user       1  8240 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533611 user       1  8325 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533683 user       1  8345 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533755 user       1  8443 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533827 user       1  8449 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533899 user       1  9700 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026533971 user       1  8481 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026534043 user       1  8635 hummel /usr/lib64/firefox/firefox -contentproc -
├─4026534114 user       1  8642 hummel /usr/lib64/firefox/firefox -contentproc -
└─4026534257 user       1 10172 hummel /usr/lib64/firefox/firefox -contentproc -

It seems the container runs in a usernamespace but root has more than one uid mapped to its uid in the parent (without any subuid entry).

What am I missing ?

[eriksjolund]

I noticed that the error message

basename: missing operand
Try 'basename --help' for more information.

is printed with the image ubi8:latest but not with the image fedora

Click me

# podman run -it --rm ubi8:latest /bin/bash
[root@a303fb00168e /]# exit
exit

# podman run -it --rm fedora /bin/bash
[root@b29d19630f06 /]# exit
exit

# podman run -it --rm --userns=keep-id ubi8:latest /bin/bash
basename: missing operand
Try 'basename --help' for more information.
[root@43626c762223 /]# exit
exit

# podman run -it --rm --userns=keep-id fedora /bin/bash
[root@d711f941db16 /]# exit
exit

# podman --version
podman version 5.2.5

[th-hummel]

About the fedora image : I noticed that registry.fedoraproject.org/fedora had no capabilities for newuidmap binary, which makes it hard to map sub usernamespaces

[rhatdan]

When building from fedora image, you could do:
RUN rpm --restore shadow-utils

[th-hummel]

Oh, indeed, it reminds now I've read about this in your book.
I was just not building from fedora but using it as is.

Thanks