Hi,

newuidmap / newgidmap consult /etc/nsswitch.conf to decide where to
get information on allowed sbuids from.
The /etc/subuid and /etc/subgid files are only used if the subid filed
in /etc/nsswitch.conf is either unset or set to files (see subuid(5)).
Otherwise the information is retrived by calling some function in a
shared object file derived from the subid value in /etc/nsswitch.conf.

I propose the retrieve the subuids/subgids by calling the getsubids
command included in the uidmap package.

I proposed a similar change to sbuild here:
https://salsa.debian.org/debian/sbuild/-/merge_requests/222


Regards,

Tobias Wiese

Hi Tobias,

does this change by Simone Caronni do what you ask?

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/966c51cec2b9ccd87707cbf305a0719d63beacec

Thanks!

cheers, josch

Hi josch,

It's similar, and it should be enough for my use case.

From 966c51cec2b9ccd87707cbf305a0719d63beacec:

This explicitly checks nsswitch.conf if subids are delegated to a plugin
called 'sss' (i.e. the one for sss(d)), and only then uses getsubids(1).
This means that this doesn't work for other subid plugins.

My patch doesn't care about the configured plugin and therefore also
delegates the scanning of /etc/subuid and /etc/subgid to getsubids if
the 'files' plugin is used.

If not delegating to getsubids when using the files plugin is preferred,
I propose to instead check if the plugin is not 'files'. Maybe a change
similar to this (untested):


Regards,

Tobias Wiese

Hi Tobias,

Quoting Tobias Wiese (2026-10-04 15:47:19)

could you discuss and agree with Simone Caronni (in CC) about the best way
forward here? I have no use nor expertise regarding nsswitch.conf and would
rely on contributors like you two to tell me what the best way forward would be
to allow your use-case for this.

Thanks!

cheers, josch