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: 2) by NotSanguine on Tuesday April 18 2017, @02:32AM (2 children)
My first thought when reading the title was: Why on earth does an init system need its own implementation of rm?
But then, this is systemd, the Borg init system. Probably I should be astonished if something has not yet been affected by it.
The "functionality" in question is part of systemd-tmpfiles(8) [fordham.edu]:
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 0) by Anonymous Coward on Tuesday April 18 2017, @02:33PM (1 child)
Given that it is meant to handle files and directories inside one or two special directories, it is really surprising that the commands are not only run as root, but allowed to exit those directories.
One would think that making use of a special config file format rather than shell scripts and core utils for this was to avoid just such events happening...
(Score: 2) by NotSanguine on Tuesday April 18 2017, @05:04PM
IIUC, there is functionality which allows the use of functions from systemd-tmpfiles in a systemd pseudo-shell. a command within that pseudo-shell (R!) purported to mimic 'rm -rf' but the function didn't treat '.' and '..' (as /bin/rm does) as special cases, making sure that deletions only occurred downwards in the directory tree.
I suppose one could make the argument that only careless users would go with 'R! .*'. However, given that /bin/rm had mitigated that issue for a number of years, (not sure when, but as a novice user back in the late 80s/early 90s I made that mistake with rm and it happily deleted half my root filesystem before I realized what was happening) by refusing to delete up the directory tree.
As such, refusing to delete up the tree is (and has been for some time) the expected behavior, so that argument is pretty weak.
Poettering, et al showed a glaring lack of common sense in their implementation and didn't consider edge cases.
No, no, you're not thinking; you're just being logical. --Niels Bohr