most init systems do have a legitimate use case for touching a file.
Can you name such a legitimate use case then? All I can think of is the need to write a pid file, and pid files are a kludge that real service supervisors gladly do away with.
Well, I want PID 1 to make exactly one userland binary call and then start reaping orphans. I want that PID 2, the RC system, to read some configuration file(s) and, yeah, fork and exec a bunch of userland binaries. It's kind of the whole point, right?
The advantage is that the kernel panics if PID 1 ever crashes, so I want PID 1 never to crash or even be able to crash. It also means I want the binary to have as little of an attack surface as possible, and particularly I don't want it listening to dbus or having links to a QR generation library.
This is a solved problem with multiple good solutions [1] [2] [3], so I can easily avoid those issues by not using systemd.
systemd does not have such functionality. You have not read the headlined message correctly.
Rather, it has functionality to "touch" files in sensitive places, and a bug that meant that they were made world-writable, world-executable, and set-UID. The headlined message alludes to the various uses of this touch function that expose such files to the world to be exploited in certain circumstances, which (amongst others) are:
* timestamp files for timer units
* device tags files in systemd-udev
* /run/udev/queue
* timestamp files used by timesyncd
* private devices, bind mounts, and mirrored /etc/resolv.conf created by systemd-nspawn
* "linger" flags used by systemd-logind
* temporary files used by "systemctl edit"
* All sorts of flag files: /run/systemd/journal/flushed , /run/systemd/quotacheck , /run/systemd/show-status , /run/systemd/first-boot
https://github.com/systemd/systemd/blob/ee735086f8670be1591f...
..and most init systems do have a legitimate use case for touching a file.