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, Funny) by maxwell demon on Tuesday April 18 2017, @01:16AM
No, of course to make it work with the command line, you'd add another layer of complexity (and another dependency). The GUI as well as each terminal or terminal emulator register themselves at the server as file selection providers. When a program asks for file selection, the server determines what file selection provider should be used for that process (which, of course, is an error-prone process which often will get surprising results), and then sends a message to the corresponding file selection provider to select a file. The GUI will open a dialog box, while the terminal will show a message and allow text input with tab completion.
The Tao of math: The numbers you can count are not the real numbers.