But then whatever app that runs as root that actually needs to update it is going to remount it rw, at which point the original problem stands.

My personal opinion is that, for the use case of a single-user machine (i.e., "Linux on the desktop"), the traditional UNIX root isn't a useful concept. What's actually sensitive is your files, your saved passwords, your browser cookies, your emails, etc.; the ability to reconfigure drivers or replace OS components is only a problem because it allows all of those things to be compromised. Instead of throwing roadblocks in the way of root (remount ro, expose it as something more complicated than a filesystem so innocent users aren't tempted to look at it, etc.), let's take all the stuff that users should be able to do and make it accessible by nonroot, and take all the stuff they shouldn't be able to do and put it in the realm of automation.

UEFI has a pretty reasonable concept here, of a distinction between "boot" and "runtime" configuration; the BSDs have a conceptually similar idea of the securelevel. The idea is that if you're around during the boot, you might be interested in reconfiguring what the machine is doing, but as soon as you're out, you permanently abjure any further ability to reconfigure that. If we take a variant on that, that the OS doesn't abjure those capabilities as a whole but instead reserves them for itself, disabling all user-controlled ability to change things, I think we get very far. You can install new software, but not change the trusted sources for software. You can apply firmware updates via an existing cronjob, but not make arbitrary changes to firmware variables. If you want to do any of that, you have to reboot and enter a special setup mode. Apart from protecting against simple human error, this also serves as a very effective protection against malware: non-OS software simply has no ability to do unwanted things.

Then let's use UNIX users (which are a pretty solid isolation technique) to isolate things like your banking info from your Flash-requiring music service.

Chrome OS, incidentally, has this concept of things the OS can do that the user has no interface to, and Chrome OS is basically the most successful Linux on the desktop, so.

> But then whatever app that runs as root that actually needs to update it is going to remount it rw, at which point the original problem stands.

There's a difference between a system which, at all times, is one mistyped command from being bricked, and a system which allows you to brick it if you're explicitly doing something dangerous in the first place.

> let's take all the stuff that users should be able to do and make it accessible by nonroot, and take all the stuff they shouldn't be able to do and put it in the realm of automation

While theoretically reasonable, this is also a huge project, and while this project is slowly implemented users are still vulnerable to this bug. Additionally, there's always going to be Linux users who find the idea abhorrent, and thus it remains a bug for those users. Choosing to have more control should not generally mean that you can brick your machine so easily as accidentally deleting a few files.

Yeah, and that app isn't rm.

Precisely how many user space apps do you think need access to it?!?

Yes. And all I see from Lennart is agreement and the statement of a few facts (some programs need access), which implies that a slightly more nuanced solution may be required. I fail to see how this reflects poorly on him.

The point is that that would offer no benefit. A root user can just mount it rw again in a single call.

So in a similar vein, why bother with alias rm='rm -i' at all?

But that doesn't actually exist by default, and so it's not a good example.

A better example is that `/` is a special case for `rm`.

(Besides: I'm not a fan of `rm -i`, precisely because it's non-default. You'll get used to it, and then someday you accidentally some files on a system where you didn't add the alias.)

Lots of GNU/Linux distributions used to it by default, has it changed?

None I currently use (just tested with bash* on: Debian, Centos, Fedora, OpenWRT) or have used in the past few years (Arch) has it.

I don't remember anything about my time with SUSE and Ubuntu, thats way back.

* I normally use zsh with grmlzshrc and nearly no customization (which is why I love grmlzshrc -- usable defaults), which warns for `rm -rf foo/*` but not for `rm -rf foo`.

Redhat based distros absolutely do enable alias rm='rm -i' out of the box, but only for the root user. As a career SysAdmin, that seems like a good compromise. If you want to take the safety net off, you can escape out the alias (or any alias) with a slash i.e.:

\rm -rf somedir

Yet by default, if you don't include the "\", you get rm -i

You're right about RedHat, sorry.

.bash_history says I accidentally added `-f` on that host. I should have just checked with `which` instead of trying it out. Oops.

Actually even if you do rm -f, the -i will still be added if it is an alias. Better is to use the bash builtin "type":

type rm is better than which rm, but it depends on what distro you're using. Some distros (Just checked on RHEL7) will fancify which as well ie:

$ type which which is aliased to `alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

> Actually even if you do rm -f, the -i will still be added if it is an alias.

Yes, I know, but rm ignores -i if -f is given.

  [root@example ~]# touch blah
  [root@example ~]# rm -i -f blah
  [root@example ~]# 

And hence:

  [root@example ~]# which rm
  alias rm='rm -i'
  	/usr/bin/rm
  [root@example ~]# touch blah
  [root@example ~]# rm -f blah
  [root@example ~]#

@type: yes, you're right, thanks for the reminder.

Maybe I am wrong but I think Red-Hat, Mandrake and SuSE used to do it.

Nowadays I spend most of my time in Windows and mobile OSes to remember it properly.

Sane distributions don't include that alias by default. Because otherwise people will always use `rm -f` and lose the feature that `rm` asks before removing files marked as read-only.

Then quite a few distributions are not sane, as I remember once a upon a time it was quite common to have it like that on fresh install.