On Tue, Apr 22, 2025 at 09:46:14PM +0200, Chris Hofstaedtler wrote: > * Serge E. Hallyn <se...@hallyn.com> [250422 15:48]: > > On Mon, Apr 21, 2025 at 08:08:50PM +0200, Salvatore Bonaccorso wrote: > > > Thought this will not really be fixable in code, it depends on how > > > uids were assigned in within a group of systems form system > > > administrators. Let's link downstream bugreport and upstream and maybe > > > they come up with a documentation update reflecting the issue? > > > > > > For further information see: > > > > > > [0] https://security-tracker.debian.org/tracker/CVE-2024-56433 > > > https://www.cve.org/CVERecord?id=CVE-2024-56433 > > > [1] https://github.com/shadow-maint/shadow/issues/1157 > > > > There is no id range that couldn't possibly conflict with some > > site's network ids. The only default safe for that concern is > > to not automatically enable any subids. > > Indeed. The question really is: what are we gonna do? > > Should there be some form of documentation update, like a README?
Maybe debian changelog? > What else would be "sufficient" to close this topic? Well, maybe we can improve one thing in adduser: when selecting subid ranges, we should exclude userids which are in use in /etc/passwd. We are currently assuming that any range above the SUB_ID_START is wholly ours. Or, maybe that should at least have a login.defs option (which then could be default-on in debian). That way all network users would need to be defined in passwd, but at least there'd be a way of doing that. Of course another alternative for the users is to implement an NSS module. While testing to make sure it isn't doing that now, I did also notice that if you do adduser --uid 200000 sj1, then sj1 does not get a subid range auto-assigned. While just adduser sj2 does. That seems inconsistent...
