FS#41711 - [systemd] 216-1 missing default preset policy

Attached to Project: Arch Linux
Opened by Jed Liu (jed) - Wednesday, 27 August 2014, 07:30 GMT
Last edited by Dave Reisner (falconindy) - Friday, 29 August 2014, 22:57 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Dave Reisner (falconindy)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 19
Private No

Details

Description:
/usr/lib/systemd/system-preset/90-systemd.preset should include "disable *". Otherwise, unless package maintainers are careful about explicitly specifying preset policies for their packages, all installed services will be enabled by default.

Steps to reproduce:
Here is an example of why "disable *" is needed.

1. Make a fresh Arch Linux installation.
2. While still booted in the Arch Linux install ISO, pretend that you'd like to have the telnet client installed and add inetutils to the installation.
3. Observe that ftpd is disabled (i.e., does not appear in /etc/systemd/system/*.wants).
4. For good measure, explicitly disable ftpd: "systemctl disable ftpd".
5. Boot into the fresh installation.
6. Observe that ftpd is enabled, started, and ready to be 'pwned'. The boot process probably flies by fast enough that the inattentive user would probably not notice for quite a long time that a bunch of extra, unwanted services are running.
This task depends upon

Closed by  Dave Reisner (falconindy)
Friday, 29 August 2014, 22:57 GMT
Reason for closing:  Fixed
Additional comments about closing:  machine-id will be properly generated on install now.

systemd-216-2
Comment by Dave Reisner (falconindy) - Wednesday, 27 August 2014, 12:35 GMT
Not following -- where are presets relevant? Arch packages never use systemctl's "preset" or "all-preset", so why do you think installing inetutils (which is what your steps boil down to) enables ftpd?

> 3. Observe that ftpd is disabled (i.e., does not appear in /etc/systemd/system/*.wants).
This doesn't strictly mean ftpd is disabled... (but isn't relevant here)

> 4. For good measure, explicitly disable ftpd: "systemctl disable ftpd".
And for some cases, this won't disable ftpd... (but isn't relevant here)

> 6. Observe that ftpd is enabled, started, and ready to be 'pwned'.
Nope. Not seeing it... What are you suggesting enabled this service?
Comment by Jed Liu (jed) - Wednesday, 27 August 2014, 16:12 GMT
Below is the full list of packages I have explicitly installed (based on 'pacman -Qqet'). Also attaching an exact list of packages I have installed, in case it matters.

I am booting with kernel parameters "systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M" and I am attaching the head of my journalctl after the first boot of the fresh install. As the tail end of the excerpt shows, something in the boot process during the first boot is looking at the presets and is enabling a whole bunch of services.

dhcpcd
diffutils
dnsutils
file
gradm
grub
inetutils
iputils
linux-grsec
logrotate
mlocate
mtr
openssh
pacman
procps-ng
psmisc
reflector
rsync
s-nail
screen
systemd-sysvcompat
tar
vim-systemd
wget
which
whois
   journal (54.8 KiB)
   packages (1.9 KiB)
Comment by Jed Liu (jed) - Wednesday, 27 August 2014, 17:36 GMT
The first-boot aspect seems important. I also forgot to mention in my original report that while ftpd.service doesn't appear in /etc/systemd/system/*.wants before booting, it shows up in multi-user.target.wants after booting.

Others on the forums are experiencing this: https://bbs.archlinux.org/viewtopic.php?id=186244

I just did a fresh "barebones" install by following the installation guide on the wiki. No extra packages were installed. With the exception of an extra 'pacman -S inetutils' (which apparently was already installed), I followed the installation guide exactly, right up to the reboot at the end of the guide. On first boot, "systemctl status ftpd" shows ftpd enabled and running. I can even connect to it from other hosts.

The following are also running, according to the output of "systemctl status": dbus, lvm2-lvmetad, dhcpcd, nscd, systemd-journald, systemd-resolved, systemd-logind, systemd-networkd, dm-event, systemd-udevd. Some of this looks normal, but others (e.g., nscd) should not be running.

The following attempted to start, but failed: iptables, ip6tables, krb5-kadmind, krb5-kdc, mdadm, systemd-journal-upload.
Comment by Marius (65kid) - Friday, 29 August 2014, 10:57 GMT
I also was just bitten by this quite annoying bug, so I tried to figure out what is happening. I think I narrowed this down. With systemd 215(!) there was a change that the equivalent of "systemctl preset-all" is called if /etc is empty. See the following commit.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=5f5c2f3855a87566e8885c7c0ae504782917a9b0

With systemd 216(!) the "is /etc empty" check has been changed with the following commit:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=baa1bdf70f21848fbe01d3f383ae0f59d86a9bf3

Since /etc/machine-id isn't created by the package, systemd considers /etc empty on the first boot and calls preset-all, therefore enabling all services. Now I don't know what the proper fix is.

- create /etc/machine-id on package install?
- Add a 99-default.preset with "disable *" as suggested in the systemd.preset man page?
- tell upstream that their "is /etc empty" check is stupid?

Personally, I would go with option 2 AND 3. ;)
Comment by Dave Reisner (falconindy) - Friday, 29 August 2014, 13:22 GMT
> Personally, I would go with option 2 AND 3. ;)
Ok, but the first item is what needs to be done regardless. I changed how this is done in 216 as a result of another bug report and was bitten by it. See my rant at upstream:

http://lists.freedesktop.org/archives/systemd-devel/2014-August/022726.html
Comment by Carl Duff (CarlD) - Friday, 29 August 2014, 19:23 GMT
Excellent - I posted a bug report about this as well. Thank you, Jed!

Loading...