SoylentNews is people
SoylentNews
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: 3, Insightful) by rleigh on Tuesday April 18 2017, @07:07AM (1 child)
I'm not so sure about that. Any implementation which doesn't handle '..' will recurse through every directory in the filesystem, and will likely never terminate because it has an infinite recursion between each parent and child. You *have* to handle '..' and '.' specially, and this isn't a recent development--it's been necessary since their invention. You'd notice this on the first invocation of your tool.
(Score: 2) by cubancigar11 on Tuesday April 18 2017, @10:38AM
You may be right. I might be confusing rm with other utilities. But I distinctively remembering waiting a long time for tar to finish when I realized it is compressing the whole system.