Stories
Slash Boxes
Comments

SoylentNews is people

Systemd-implementation of "rm -rf" Buggy, Could Erase Root Partition

posted by cmn32480 on Monday April 17 2017, @08:34PM   Printer-friendly
from the people-that-live-in-a-bubble dept.

Soylentbob writes:

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).

Original Submission

 
This discussion has been archived. No new comments can be posted.
Systemd-implementation of "rm -rf" Buggy, Could Erase Root Partition | Log In/Create an Account | Top | 172 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by NotSanguine on Tuesday April 18 2017, @05:04PM

    by NotSanguine (285) <{NotSanguine} {at} {SoylentNews.Org}> on Tuesday April 18 2017, @05:04PM (#495913) Homepage Journal

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

    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
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2