Edit: The link.
There were lots of good titles for this submission, as in "Breaking news: Poettering clueless?" to finally disprove Betteridge's law, or "systemd surprisingly not as good as advertised" or "Breaking new: systemd broken" or "Poettering censors critics after epic fail".
Systemd implementation of "rm -rf .*" will follow ".." to upper directory and erase /
How to reproduce:
# mkdir -p /foo/dir{1,2}
# touch /foo/.bar{1,2}
# cat /etc/tmpfiles.d/test.conf
R! /foo/.* - - - - -
Reboot.
After the issue was fixed, finally Poettering added this gem of wisdom:
I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
The answer to this question, as many clarified for him, obviously is a loud "NO!". After being told a couple of times in no uncertain terms, the thread was closed for non-developers
poettering locked and limited conversation to collaborators 4 hours ago
for which I proposed the "freedom-of-speech" department (although I admit it is a weak proposal).
(Score: 4, Informative) by rleigh on Monday April 17 2017, @11:26PM
The OS doesn't stop you, only the standard behaviour of rm(3) which they weren't using. If you implement a recursive delete, you need to unlink(2) and rmdir(2) every file and directory in a recursive fashion. Checking that you never follow '..' is the programmer's responsibility. One of the first things you learn when systems programming and walking directories is that '..' needs special handling. Truly amazing these "skilled experts" did this; it really is amateur hour in the systemd world.