Rootless Podman Without Pre-Configured subuid/subgid

[nlvw]

Recently the Apptainer project released a new version that no longer requires /etc/subuid and /etc/subgid to be preconfigured for running/building rootless containers. The only requirement is that unprivileged user namespaces be enabled. This is really convenient as AD users can both build and run containers without an admin having to setup subuid/subgid configuration. All while being rootless with no setuid binaries.

It would be nice if rootless podman could also do this as it is unusable at scale in a SSSD (ldap/ad) environment. Preconfiguring subuid/subgid bindings for every potential users who could login and then syncing those binding across multiple machines (10s to 100s) is not a solution.

https://github.com/apptainer/apptainer/releases/tag/v1.1.0

[afbjorklund]

There is the ignore_chown_errors storage option, which is somewhat similar to fakeroot perhaps:

https://www.redhat.com/sysadmin/controlling-access-rootless-podman-users

Allowing to run without setting up subuid and subgid is a good feature, and an improvement over docker...

Otherwise there needs to be some user-accessible service, on how to "request" a mapping to be set up ?

[jhodrien]

Quite probably, yes. I'm interested in whether buildah/podman can support something equivalent to the third in the list here:
https://apptainer.org/docs/user/main/fakeroot.html

[rhatdan]

Not yet, although adding something like --isolation=fakeroot, to buildah and podman build would likely be approved.

[cbs228]

Otherwise there needs to be some user-accessible service, on how to "request" a mapping to be set up ?

We already have oddjob-mkhomedir for creating user home directories in SSO environments. What about a mythical "oddjob-mksubuid" to create a /etc/subuid mapping on first login? While there are plenty of SSO environments that exceed 32k users, how many individual machines see that many different logon users? There might be some cluster head nodes that do… but how many of those also want to run rootless containers?

Assigning subuids on first-login is fraught with peril. The safest uid range to use is the one that FreeIPA already does, but that makes an eventual collision a near certainty. Since SSO machines would not share uid mappings, you couldn't just rsync a podman volume from one to the other. Restores from backup would also not work unless /etc/subuid was also restored. There are already problems with rootless images and NFS, and this certainly won't make them any better. The potential for accidentally cross-contaminating subuid ranges is also greater than if they were centrally-managed.

There is an experimental pam_subuid already that does almost exactly what I've described. It would probably be better as a message-oriented oddjob service. That way, potential race conditions due to multiple "first" logins could be handled more gracefully.

Of course, the real "fix" would be to convince the kernel folks to widen uid_t to int64_t or larger. Then everybody on Earth could have a subuid range! (Once we manage to fix the apocalyptic impact this would have on filesystem drivers and everything else.) Yes, this is probably not going to happen.

[rhatdan]

@nalind WDYT?

[nalind]

The --isolation flag only factors in for builds when RUN instructions are being evaluated, so it wouldn't be exposed that way. We'd be looking to affect how podman itself handles setting and verifying ownerships on layer contents, and all of that happens well before a container is even created.

My main doubt is that using LD_PRELOAD to have a shared library intercept calls into libc for a process doesn't work if the binary isn't dynamically linked, or if the shared library isn't there because the process is being run in a mount namespace where the shared library doesn't exist. fakechroot and psuedo also use LD_PRELOAD. fakeroot-ng uses ptrace(2), which we tend to not allow the capability for.

The API surface is large, and I doubt that any of the available options covers everything. I would be hesitant to depend on images which were built using them.

[eslowney]

FreeIPA/IdM already hands out subuids to users, which getsubids $USER correctly spits out, but podman insists on reading /etc/subuid for some reason. I don't understand why it doesn't query /etc/nsswitch.conf and/or SSSD instead of reading files.

[eslowney]

If anyone's curious, I figured out my issue. Even if you are using SSS in /etc/nsswitch.conf, the files /etc/subuid and /etc/subgid must exist, even if just empty 0-bytes files.

$ rm -f /etc/sub?id
$ podman system migrate
ERRO[0000] running `/usr/bin/newuidmap 12333 0 1995600002 1 1 2147483648 65536`:
Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1
$ touch /etc/subuid /etc/subgid
$ podman system migrate
$ 

[rhatdan]

That would seem like a bug.
@giuseppe PTAL

[giuseppe]

what do you get with the command unshare -r --map-auto cat /proc/self/uid_map?

[eslowney]

what do you get with the command unshare -r --map-auto cat /proc/self/uid_map?

The RHEL 9.3 version of unshare (2.37.4) doesn't have --map-auto, but w/o it:

$ unshare -r cat /proc/self/uid_map
$            0 1995600002            1

I'm going to upgrade this box to 9.4 shortly, maybe there will be different behavior.

[giuseppe]

so newuidmap/newgidmap refuse to configure the user namespace, it doesn't depend on Podman