Hi! On Mon, 2025-05-12 at 22:52:53 +0200, Simon Josefsson wrote: > Marco d'Itri <m...@linux.it> writes: > > On May 12, Simon Josefsson <si...@josefsson.org> wrote: > > > Having some mechanism to create package-specific users seems like one > > > useful goal, and I don't understand why each package has to write > > > scripts to invoke 'adduser' and deal with all the complexity around that > > > on their own. There could be a declarative interface a package can use > > > and say 'USERS+=saned' or 'USERS+=munin' or 'USERS+=openldap' and that's > > > it.
> > We have one: it is documented in sysusers.d(5). > > Now you just need to persuade everybody to use it. > > Oh I wasn't aware of that, thanks for the pointer. Is there any known > reason (except lack of time) that people aren't using it? I'll see if I > can come up with a way to use it in some packages, I think 'pqconnect' > would be a good candidate -- the postinst script is only there to call > addgroup+adduser and it always felt like a hack. > > https://salsa.debian.org/python-team/packages/pqconnect/-/issues/13 systemd's sysuser support is only apparently slightly better than adduser (in that it is declarative), otherwise it feels rather underwhelming in the package management context. It does not solve being able to use such users in .deb files w/o maintainer scripts, it currently also uses maintainer scripts for its normal operation (you just do not write them explicitly), it does not solve bootstrapping issues, does not support setting a system-wide policy on whether to remove the users/groups on package purge, etc. I still think the right way forward is to add proper native support for system user/groups to dpkg, where the first stage was implemented recently by portably parsing passwd and group files natively (to support chroots). I'm planning to discuss this with the base-files and adduser maintainers, to have a draft for dpkg 1.23.x. Thanks, Guillem
