Systemd: tmpfiles: R /dir/.* destroys root | Hacker News Reader

.* destroys root

github.com

46 pointsthe_mitsuhiko20 comments

This almost seems like a generational clash. Anybody who's been around for a while knows that you never ever type rm -rf .* because it can blow up in your face. Lennart's response is tone-deaf because he can't understand how anybody could make that mistake. He's never noticed that rm has started refusing to let you shoot yourself in the foot because he would never think of typing rm -rf .* in the first place. Newer users have never had the opportunity to shoot themselves in the foot with rm and are now tripping over systemd. For all the criticism of systemd not being unixy, this bug reproduces classic unix behavior!

edit: unintentional italics

I don't think Lennart is from a generation that would have experienced this.

http://pubs.opengroup.org/onlinepubs/007904975/utilities/rm....

"The rm utility is forbidden to remove the names dot and dot-dot in order to avoid the consequences of inadvertently doing ..."

Please bear in mind that (1) the existence of a standard does not imply immediate global compliance of new software and (2) the existence of compliant software does not imply that people are actually using it. In the 1990s, when Lennart would have been at university, he would have been exposed to Unix servers that had been installed 5-10 years previously, at least. So the timeframe we're looking at isn't 2001, but the late 1980s / early 1990s.

If he is programming for _nix, but has not kept himself current with developments within the _nix ecosystem, that is even more worrying.

My sympathy is clearly with Lennart here -- we're around the same age, and I like using systemd. I came of age using systems that would absolutely burn you if you tried to remove .* and it's pretty unreasonable to ask me to remember that most users wouldn't have a reason to reflexively avoid it.

You're on much firmer ground arguing that Lennart shouldn't be reimplementing rm. I disagree -- I don't have a problem with him reimplementing rm in systemd -- but there's a legitimate argument to be made there.

Nah, it is more a clash in that not only do the systemd devs feel the need to make their own rm equivalent. But they fail to look into the evolution of defaults for said command before going "its unix, deal with it".

Yeah it is unix, it is the kind of unix that you only find running on some old DEC somewhere. Not on a modern x86 cluster.

This while presenting systemd as being about making Linux something more than a unix clone.

And when people complain about systemd not being unix, it is about how everything is blobbed together via interfaces that keep changing at the whim of the developers.

This in contrast to how someone can pipe the output of a GNU command to the input of a BSD command and get sane results, because the interfaces are known and fixed.

People would be much more accommodating of systemd if the logind part could be used independently of the init part etc.

FWIW, the bug was fixed before Lennart even started the whole discussion.

> it is more a clash in that not only do the systemd devs feel the need to make their own rm equivalent

I disagree. It's a failure of the C standard library to not provide a recursive unlink(), so every C program that wishes to do one has to reimplement the logic manually. Most standard libraries of other languages have a recursive unlink(), for example: https://golang.org/pkg/os/#RemoveAll

That bug is like the quintessence of why systemd is bad. Breaking the system when getting user input that previously worked, not even knowing that the existing tools they replaced had safe-guards against this problem, and when confronted with the issue having a first reaction of "that's not a problem".

The one good thing about this is that they did not close it as 'won't fix'.

The first reaction was to fix the bug. The discussion started after that.

> The one good thing about this is that they did not close it as 'won't fix'.

My educated guess based on reading several previous bug reports is that Poettering would've drag his feet and maybe first close it as wontfix before fixing the issue some time later. Thankfully Martin Pitt fixed it quickly before Poettering came over to badmouth UNIX and point out how everybody else is wrong.

For people jumping straight to comments: it is not so much about issue itself (which IS pretty bad), but more about sloppy off-hand comment from a systemd maintainer, and systemd opposition that did not miss a chance to pile up.

This is what happens when you try to reinvent what could be achieved by shell scripts and basic command line utilities.

Because no one would every do rm -rf / in shell?

irrelevant

> 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?

says Poettering.

Really interesting how quickly this vanished off the front page...

hackernews has heuristics for controversial topics and down rate them automatically.

"@poettering locked and limited conversation to collaborators 34 minutes ago."

That's why I submitted it only now.

The bug is already fixed and they have better things to do than messing with our trolling. :-)

Reply on news.ycombinator.com