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, Troll) by Ken_g6 on Monday April 17 2017, @09:28PM (10 children)
(Karma to burn)
I heard `rm -rf .*` would erase things up the .. chain years ago. I didn't know it was a bug.
Then again, I'm not a developer of any Linux system utilities. I also don't disagree with changing the behavior.
(Score: 2) by wonkey_monkey on Monday April 17 2017, @09:49PM (4 children)
I'm not sure I'd call it a bug either. It should be fairly clear that it's a stupid thing to do without checking, but also yes, it's probably best all round that the OS stops you, but a bug?
systemd is Roko's Basilisk
(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.
(Score: 5, Insightful) by sjames on Tuesday April 18 2017, @03:38AM (2 children)
Definitely a bug. Utilities are supposed to descend only when given the recursive (-r) flag. Ascending is incorrect. Beyond being wrong based on the definition of the flag, ascending reduces the semantic expressiveness of the -r flag. If I actually WANT to recurse over the entire file system when it descends only, I can specify "-r /", but if it also ascends I have no way to specify here and below.
I'm not surprised that he would screw semantics up that way, the unit files implement COMEFROM logic.
(Score: 0) by Anonymous Coward on Tuesday April 18 2017, @10:36PM (1 child)
> the unit files implement COMEFROM logic.
...wut...
(Score: 3, Interesting) by sjames on Wednesday April 19 2017, @12:40AM
That's what I thought when I saw it. COMEFROM [wikipedia.org] is a humorous suggestion as a counterpart to GOTO. It's frequently considered a GREAT way to encourage impossible to debug obfuscated code.
By allowing a unit file to declare that another unit depends on it, systemd effectively implements COMEFROM with all of the pitfalls that entails.
(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?
(Score: 1) by DeVilla on Tuesday April 18 2017, @03:16AM
I've heard stories of Admins from the DOS/Win32 world who would be forced into the UNIX world and as root, on a system with root access over NFS would run:
cd /tmp
rm -rf *.*
Actually it would be 'del -rf' because people would actually alias up del, dir, etc. And yes, once this would delete everything until the system hung or crashed.
(Score: 2) by FatPhil on Tuesday April 18 2017, @07:52AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Tuesday April 18 2017, @02:30PM
Yes and no. Rm implementations on most _nix these days have code that checks if you are trying to delete he root directory.
https://linux.die.net/man/1/rm [die.net]
--preserve-root
do not remove '/' (default)