1. 19

  2. 8

    It is typical, and has been for at least the decade I’ve been using Linux, to put root’s home directory in /root to mitigate precisely this issue:

    $ fgrep root /etc/passwd

    However, a script like that is still a bad idea that would give me the heebie-jeebies even if it had additional checks in place. It’s fairly typical for users to intentionally have unusual ownership in their home directory (especially system users, but real users as well). A better solution would have been to map UIDs and change ownership as part of the copy.

    1. 3

      root’s, yes. But there often are other users whose home directory is /. E.g., on my Linux box:

      grep :/: /etc/passwd | wc -l

      (6 on FreeBSD). All of those have /.../nologin as their shells.

      1. 4

        Indeed. I have no users with / as a home directory, but bin, proxy and sync have /bin, sys has /dev, and daemon has /usr/sbin, all of which would be highly destructive to chown.

        I assume the reason only root is sandboxed like this is that it’s assumed nobody would be foolish enough to run something like the script in the article, but you might very easily accidentally do something destructive to “your” home directory as root. After all, it’s very common to su to root, but significantly rarer to su to e.g. sys.

        (As a piece of actionable advice, before firing off a potentially destructive script like that, I like to prefix the dangerous bits with “echo” and read carefully over what it says it’s going to do. Hopefully seeing “chown -R root /” would be sufficiently eyebrow-raising to prevent any damage.)

        1. 4

          echo the commands first for sure. I do that for anything that would take me longer than 30 seconds to un-fuck.

          1. 2

            Same here. And if you like the output, just add | sh.

    2. 5

      I chuckled, but this isn’t “Unix screwing up”, it’s the author running a horribly scary script.

      1. 5

        Since I usually adhere to the quite intelligent convention of having /home/* actually respect user names, I would just:

        for dir in /home/*; do
            chown -hR "${dir##*/}" "${dir}" || break

        Touching some unknown directories of whatever the auxiliary users are sounds like a bad idea in any case.

        On the other hand, I managed to wipe my entire system using tar. Nothing about tar -xC / --unlink-first --recursive-unlink sounded like a bad idea at the moment.

        1. 4

          I forgot to write that the title could’ve been straight out of the UNIX Hater’s Handbook. Relevant section that might have used the title:

          “This is the fifth day I’ve used a Sun. Coincidentally, it’s also the fifth time my Emacs has given up the ghost. So I think I’m getting a feel for what’s good about Suns. One neat thing about Suns is that they really boot fast. You ought to see one boot, if you haven’t already. It’s inspiring to those of us whose LispMs take all morning to boot.”

          “Another nice thing about Suns is their simplicity. You know how a LispM is always jumping into that awful, hairy debugger with the confusing backtrace display, and expecting you to tell it how to proceed? Well, Suns ALWAYS know how to proceed. They dump a core file and kill the offending process. What could be easier? If there’s a window involved, it closes right up. (Did I feel a draft?) This simplicity greatly decreases debugging time because you imme- diately give up all hope of finding the problem, and just restart from the beginning whatever complex task you were up to. In fact, at this point, you can just boot. Go ahead, it’s fast!”

          “One reason Suns boot fast is that they boot less. When a LispM loads code into its memory, it loads a lot of debugging information too. For example, each function records the names of its arguments and local variables, the names of all macros expanded to produce its code, documentation strings, and sometimes an interpreted definition, just for good measure. ”

          “Oh, each function [on LispM] also remembers which file it was defined in. You have no idea how useful this is: there’s an editor command called “meta-point” that immediately transfers you to the source of any function, without breaking your stride. ANY function, not just one of a special predetermined set. Likewise, there’s a key that causes the calling sequence of a function to be displayed instantly.”

          “Unix programs (such as the Sun window system) are stripped as a matter of course, because all the debugging information takes up disk space and slows down the booting process. This means you can’t use the debugger on them. But that’s no loss; have you seen the Unix debugger? Really.”

          Fun times in 1987. Things have gotten a bit better but not LispM better. I’m still waiting for a UNIX with its development, debugging, and extension capabilities. Would be badass. :)

          1. 2

            Did you mean to duplicate the 2nd quoted paragraph?

            1. 1

              Great catch. Cut and paste error. I put the correct paragraph in there. It should make more sense slash be more impressive on LispM side now. :)

          2. 1

            In FreeBSD, the tool to recover from such a mistake is mtree(1). I recommend people learn it and take dumps of all non-OS files regularly with cron to save your butt.

            It’s also a powerful tool for doing intentional UID/GID changes: take dump with mtree, change UIDs/GIDs of users on the system, and apply the mtree dump to fix everything.