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: 0) by Anonymous Coward on Tuesday April 18 2017, @01:50AM (1 child)
DOS used to do that. If you deleted the . file the system would crash and you'd get no useful data off the disk. FreeBSD hasn't done that in the decades I've been using it. Same goes for Linux, I've never typed that into Linux and had anything other than all the files and directories starting with a . deleted.
The bug here is that the . isn't supposed to be treated like a regular file or directory. It's something that's used to represent the current directory in the same way that the .. is there to represent the directory that the current directory is in. They require special treatment or weird things happen.
(Score: 0) by Anonymous Coward on Tuesday April 18 2017, @02:45AM
I think possibly before glibc 2 though, so maybe libc4 libc5 era. And I am not sure which rm implementation it was (maybe one used on an early version of Slackware?