subid ranges are ignored for owners/users that have no passwd entry (v4.2.0)

[ffernand]

Sub ID ranges whose owner/user has no /etc/passwd entry are silently ignored. getsubids reports no ranges for such a user even though the entry is present in /etc/subuid. Entries owned by a name that deliberately has no account are now silently invisible.

Reproduction

$ printf 'phantom:900000:65536\n' | sudo tee -a /etc/subuid
$ getsubids phantom
Error fetching ranges
$ echo $?
1

Entries in the same file owned by an existing account are unaffected and return their ranges normally. The only thing that differs is whether the owner exists in /etc/passwd.

I discovered this when using Podman's rootful --userns=auto, resulting in this error...

ERRO[0000] Cannot find mappings for user "containers": no subuid ranges found for user "containers" in /etc/subuid
Error: creating container storage: not enough unused IDs in user namespace

Podman allocates ranges from an owner named containers, and it's mentioned in a podman discussion that it doesn't need to be a real account (though this might be advice no longer relevant).

podman-container-tools/podman#24951

I couldn't tell if requiring a passwd entry is intentional or not. But until 4.20 it wasn't required...

[alejandro-colomar]

A git-blame(1) session with your reproducer points to 0f71398 (2026-03-29; "subid: use is_same_user() for owner resolution in range queries"), merged in #1573.

Cc: @jcpunk , @hallyn

[jcpunk]

I'm not sure how you'd access subids for a user without an entry in /etc/passwd. Without the ability to become the "owning" user, wouldn't they be meaningless?

[hallyn]

jcpunk left a comment (shadow-maint/shadow#1710) I'm not sure how you'd access subids for a user without an entry in `/etc/passwd`. Without the ability to become the "owning" user, wouldn't they be meaningless?

I suppose they (podman) started as root and did setresuid(unused_uid, unused_uid, unused_uid)? Although I see no evidence of that in their source. I could just be missing it.

[jcpunk]

If you've started podman as root I'm not sure there would be any actual restrictions on what subids you've got access to. That, I fear, is beyond me.

[hallyn]

On Thu, Aug 13, 2026 at 08:53:37AM -0700, Pat Riehecky wrote: jcpunk left a comment (shadow-maint/shadow#1710) If you've started `podman` as `root` I'm not sure there would be any actual restrictions on what subids you've got access to. That, I fear, is beyond me.

root actually is (iirc) restricted to subids listed for user root in /etc/subuid, but I don't think that matters here. I agree I'm not sure this is a useful "feature" to maintain.

[hallyn]

On Tue, Aug 04, 2026 at 07:44:12AM -0700, Pat Riehecky wrote: jcpunk left a comment (shadow-maint/shadow#1710) I'm not sure how you'd access subids for a user without an entry in `/etc/passwd`. Without the ability to become the "owning" user, wouldn't they be meaningless?

Actually, given the comment in that podman issue, I think the *intent* from podman was to have a 'containers' user in /etc/passwd which has subuid entries; that some people didn't create that user, and didn't notice because it worked anyway; and that now they have to create that user. As for why go through this when root can have subuids, I assume the point would be to drop privs earlier so that the container pre-init is also done by 'containers' user rather than root.

[jcpunk]

I would think in that case you'd want an actual user to exist so that the subids are correctly mapped for the audit logs?

[hallyn]

On Thu, Aug 13, 2026 at 11:08:06AM -0700, Pat Riehecky wrote: jcpunk left a comment (shadow-maint/shadow#1710) I would think in that case you'd want an actual user to exist so that the subids are correctly mapped for the audit logs?

Agreed.

[Luap99]

Actually, given the comment in that podman issue, I think the intent
from podman was to have a 'containers' user in /etc/passwd which has
subuid entries; that some people didn't create that user, and didn't
notice because it worked anyway; and that now they have to create that
user.

Yes, the intent is to have the range defined in the file so the same range will not get assigned to other users to avoid the uid/gid overlap. Rootful podman just uses it as DB lookup to know what range to pick from for the "auto" mode, it does not use the new{u,g}idmap helpers as it already runs as root and can assign any IDs.

https://github.com/podman-container-tools/podman/blob/main/troubleshooting.md#44-sudo-podman-run---usernsauto-fails-with-cannot-find-mappings-for-user-containers

That shows the user should be created. Though like you said podman does not care or need it, we just lookup the ranges from the subuid/subgid files and that used to work.