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, NielsOn 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
