Rachel Barker

Today's sysadmin discovery:

So, for all that I like Debian, one big sticking point I've had with it is that when you install a package which contains a system service, even if it was pulled in as a dependency of something else, that service gets auto-enabled, with a default configuration.

That has always felt like bad security practice to me, as it means any update can suddenly expose new services to the outside world without warning. It's also subtly broken my setup on at least two different occasions.

Fortunately, there is a way to change the default policy, so that new services only get enabled when you tell them to be:

https://manpages.debian.org/trixie/systemd/systemd.preset.5.en.html (example 1)

Definitely going to put that in my ansible configs!

systemd.preset(5) — systemd — Debian trixie — Debian Manpages

Feb 25 at 10:51pmWeb
Show threadAbhijit Menon-SenFeb 25
@rachelplusplus The recommended way to do this used to be by creating a /usr/sbin/policy-rc.d with an exit status of 0 or 1 or something. This systemd.preset mechanism looks simpler and much more convenient to use. Thanks for the tip!
Show threadRachel BarkerFeb 25
@amenonsen I did see that approach being mentioned on stackexchange, as well as in some documentation which seemed to date back to Debian 3 (!). I haven't tested whether that still works alongside the systemd mechanism, or if it was fully replaced.
Show threadMaxFeb 26

@rachelplusplus Be aware that adhering to this preset mechanism is up to the packagers (the installation scripts need to check for the setting), and in my testing of using Debian for one of our cloud environments, I found out that some services will happily ignore it, and got autostarted anyway.

I'm in the same boat as you, I like Debian to bits, but this "autostarting ALL the things!" is a show stopper for me.

Show threadDavid Chisnall (*Now with 50% more sarcasm!*)Feb 26

@rachelplusplus

FreeBSD has the opposite policy: the post-install message tells you how to enable the service. It’s a common source of complaints, especially for things installed as dependencies (for example, you install KDE, it brings in things like dbusd, which it requires, but you need to manually enable it. As an end user, you have no idea what dbusd is or why KDE needs it, it’s just an implementation detail).

Show threadRachel BarkerFeb 26

@david_chisnall I'm not sure if FreeBSD has this mechanism, but systemd units can specify dependencies on other units. So in theory that should be solvable; I'll have to try it for a while and see if there are any issues in practice.

(I suppose that does re-introduce the "services I didn't explicitly enable are running" problem, just on a hopefully smaller scale. C'est la vie.)

Show threadBobFeb 26
@rachelplusplus That's gold! Thanks for sharing!
Show thread🏳️‍⚧️ Chloé: IA VeganFeb 26
@rachelplusplus
Really interesting!
I learn something, and checked on my Arch Linux.
It was disabled by default (I can conclude Arch do it right).
Show threadRachel BarkerFeb 26
@jenesuispersonne Yep, I've used Arch in the past and not enabling things by default was one of the things I liked about it. And if Debian's behaviour wasn't changeable, I would have moved back to Arch over it.
Show threadDarac MarjalFeb 26
@rachelplusplus Also check out https://manpages.debian.org/unstable/policy-rcd-declarative/policy-rc.d.8.en.html which I think is what chroots use so they don't try to start services
policy-rc.d(8) — policy-rcd-declarative — Debian unstable — Debian Manpages

Show threadRachel BarkerFeb 26
@darac I guess that answers what @amenonsen and I were talking about - that mechanism does still exist in Debian, alongside the systemd-based one. Good to know!