Hi Niels, Please close+wontfix. Today the 1-999 range is reserved for the vendor usage, at build time. Special local cases have the range 1879048192-4294967294 available to choose from, that doesn't clash with the 'human' user id range, which should hopefully be enough for dozens of years. It is not the 1980s anymore, and the uid range does not stop at 65k. This is documented in detail at https://systemd.io/UIDS-GIDS/ Yes, this is not how "things used to work", and that's ok, stuff can change. Thanks.
On Sat, 11 Jan 2025 at 19:19, Niels Thykier <ni...@thykier.net> wrote: > > Hi Luca, > > Can you review this one and comment? I am happy to change the debhelper > snippet, but I would need guidance on what to change to avoid breakage. > > Best regards, > Niels > > > On Wed, 24 Jul 2024 02:12:19 +0000 Jamie Heilman > <ja...@audible.transient.net> wrote: > > Package: debhelper > > Severity: important > > Version: 13.11.4 > > > > Let me start by saying, the pain felt in #1029785 is relevant here. > > The problem is somewhat different, but the basic set of conditions is > > the same. Sysadmins need to have control over the ranges that users > > are created in in their environments, and the last several releases of > > Debian have been making that more and more frustrating to accomplish. > > > > When package policy dictated that everybody was to use adduser, this > > wasn't an issue. Admins configured login.defs, adduser followed the > > rules present there, and having a working uid/gid allocation policy > > was doable. Then systemd came along. In Debian 9, it wasn't a huge > > problem yet, systemd-sysusers was barely used, certainly nothing vital > > used it. In Debian 10 its behavior of doing top down id allocation > > become much more noticable as on first boot systemd-sysusers would > > ensure configured users existed (a freshly dbootstrapped system would > > usually see a this take effect) and it started clobbering uids > > traditionally out of bounds by our local policies. Annoying, but easy > > to work around, we configured a /etc/sysusers.d policy that protected > > our local ranges and things were good again; it was a little precious > > having to keep both login.defs and our sysusers.d policy in sync, but > > it's entirely doable. Users created on boot by systemd-sysusers would > > now follow the same policy that adduser follows. (My local policy > > dictates that uid/gid 600-999 are reserved, so my new sysusers.d > > policy was simply "r - 100-599" which worked fine.) Now here we are > > with Debian 12, at some point debhelper grew a dh_installsysusers > > which uses the postinst-sysusers autoscript and generates postinst > > hooks; those postinst hooks make things significantly more > > frustrating, and packages in Debian 12 are using them more than they > > did in 11. > > > > The problem is that the hooks call systemd-sysusers with a config file > > argument. When systemd-sysusers is invoked that way, it (to quote > > from the manual): > > > > ... just the configuration specified by the command > > line arguments is executed. > > > > The effect of this is that system users get created by debian packages > > using dh_installsysusers in a way that completely ignores policy > > established in /etc/sysusers.d *unless* that policy is established in > > files that override every single sysusers.d config also shipped in a > > package. To use a concrete example, systemd-timesyncd used adduser in > > its postinst script in Debian 11, and uses systemd-sysusers as of > > Debian 12. To protect my systems against this package creating its > > system user in my reserved range I now have to create a > > /etc/sysusers.d/systemd-timesync.conf file before installing the > > package ... and I have to do this for _every_package_ that used > > dh_installsysusers. It's not immediately clear to me if calling > > systemd-sysusers without explicit configs is going to be safe in the > > context of a postinst script (only because I haven't spent a lot of > > time thinking about it), but what is clear is that debhelper's > > approach to using systemd-sysusers is making it difficult for > > sysadmins to actually have and enforce a policy of what uid/gid ranges > > are safe to use. > > > > So now admins have to fight this system, one package at a time, which > > is incredibly awkward, and really does not strike me as the intended
