5 ms·

These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an

These threads are never productive. Running rm -rf / is going to offer multiple interesting ways to make your life miserable, eg: a mounted FUSE filesystem, an NFS folder pointed somewhere important, Samba mounts from your network automatically connected from your desktop, etc. I wouldn't be surprised if you could nuke firmware off a device by deleting the appropriate file in /sys/. Systemd hate is en vogue these days so they are an easy and common target. Why no invective towards the kernel that actually implements EFI-as-a-filesystem?

voltagex_ 11y ago
Yeah but you can normally recover from that without a soldering iron. Badly implemented EFI is out there.
cmhamill 11y ago
The issue here is actually bricking the device. It's not your standard "do we let people hang themselves or limit the user's capabilities" debate. A filesystem is a perfectly reasonable way to implement access to the EFI vars.
dkarapetyan 11y ago
Because everything is a file in unix derivative land. That is a common accepted practice at least but optimizing for the common case here is the right thing to do. How often do people need to manage EFI things through the filesystem and how much of an inconvenience is it to have the initial mount be read-only? The answer is obvious to me because I know people run `rm -rf` often enough that having a safeguard in place is the right thing to do.
- SFjulie1 11y ago
  A file maybe, a filesystem no. You can't 'ls' your network connections. And for tricky API that does not match the filesystem view we have the fnctls.
  - dkarapetyan 11y ago
    With fuse you certainly can.
    - SFjulie1 11y ago
      Yeah. Never coded a driver did you? It is as smart as saying that by using a hammer heavy enough you can make a cube fit in a triangle. It is possible, but defeating the purpose of consistent API.
      - deleted 11y ago
        [deleted]
  - 4ad 11y ago
    > You can't 'ls' your network connections. You sure can in Plan 9. Unfortunately (?) Plan 9 is more Unix than Unix itself.
mikeash 11y ago
Sometimes people run rm -rf / just for fun before reformatting a system, just to see what happens. Given that its purpose in life is to delete files, it stands to reason that running this command on a system which contains no important data is OK. A default configuration which makes this command destroy hardware is not reasonable.
- kbenson 11y ago
  rm -rf / probably doesn't do what you think it does. The coreutils version of rm includes --preserve-root[1], which is the default[2]. It also supports --one-file-system, which would prevent this and a host of other problems as well. That said, I don't really see a problem with Lennart's response. It's basically, "we should take steps to make this hard to do, but root is capable of doing anything, so don't expect it to be foolproof." 1: https://www.gnu.org/software/coreutils/manual/html_node/rm-invocation.html https://www.gnu.org/software/coreutils/manual/html_node/rm-i... 2: https://www.gnu.org/software/coreutils/manual/html_node/Treating-_002f-specially.html#Treating-_002f-specially https://www.gnu.org/software/coreutils/manual/html_node/Trea...
  - mikeash 11y ago
    Is there some response besides the one linked here? Because all I see here is basically saying, "We're not going to change anything, this is not a problem, remount it yourself if you don't like it."
    - kbenson 11y ago
      He says "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root." That looks like agreement that it needs something done to me. I took the followup comment to be a useful to on how to mitigate the problem until then.
      - mikeash 11y ago
        Isn't it already only writeable by root? The request is to make it not even writeable by root without taking some additional action to make it writeable first. If I understand correctly, that bit you quote just describes the current situation.
krylon 11y ago
> Systemd hate is en vogue these days To be fair, Lennart Poettering could probably end war and famine forever in a single day, and some people would still find something wrong with that. On the other hand a certain amount of skepticism and criticism is very much in order. (I am saddened, though, by the way online discussions so easily deteriorate into name-calling and bitter ranting.) Just to be clear, I was highly skeptical of systemd initially, now I have two systems running Debian Jessie, and quite honestly I haven't noticed much of a difference one way or the other. So at least now I am more confident that we are not all going to die because of systemd. On the other hand, I wish there had been more initial coordination / portability work to make sure stuff like GNOME keeps working smoothly on *BSD as well.
- bigbugbag 11y ago
  On the other hand I was happy and welcoming of systemd then I started to experience way too many breakage due to attitude of the devs. When you have to spend 2 days to get to a remote server room and back because suddenly systemd decided that a device in fstab not present at boot would halt boot with error and at the same time the emergency shell was broken and going into a loop of asking for credentials, on a debian server, in production. Ok systemd works most of the time but after experiencing a few of these breakages I've become wary of anything systemd. Whatever it brings to the table is not worth the wasted time and headaches it causes.
  - krylon 11y ago
    Oh my, that is bad indeed. Apart from the two-item sample of personal experience I am kind of torn about systemd - some of the problems it attempts to address are real, and addressing these in general seems like a good idea. The way it does so, however, sometimes (I am being deliberately vague here) brings along some problems of its own.[1] And the further systemd adoption and systemd's mission creep go along, the harder it becomes to backtrack and replace it in case somebody comes up with a better solution. [1] Like I said, I have not experienced any of these problems myself, but I have read a couple of reports from people that had problems with systemd that were definitely not just aesthetic.
bigbugbag 11y ago
This is not what actually happened when this was reported on arch linux forums: https://bbs.archlinux.org/viewtopic.php?id=207549 https://bbs.archlinux.org/viewtopic.php?id=207549

voltagex_ 11y ago

Yeah but you can normally recover from that without a soldering iron. Badly implemented EFI is out there.

cmhamill 11y ago

The issue here is actually bricking the device. It's not your standard "do we let people hang themselves or limit the user's capabilities" debate. A filesystem is a perfectly reasonable way to implement access to the EFI vars.

dkarapetyan 11y ago

Because everything is a file in unix derivative land. That is a common accepted practice at least but optimizing for the common case here is the right thing to do. How often do people need to manage EFI things through the filesystem and how much of an inconvenience is it to have the initial mount be read-only? The answer is obvious to me because I know people run `rm -rf` often enough that having a safeguard in place is the right thing to do.

SFjulie1 11y ago
A file maybe, a filesystem no. You can't 'ls' your network connections. And for tricky API that does not match the filesystem view we have the fnctls.
- dkarapetyan 11y ago
  With fuse you certainly can.
  - SFjulie1 11y ago
    Yeah. Never coded a driver did you? It is as smart as saying that by using a hammer heavy enough you can make a cube fit in a triangle. It is possible, but defeating the purpose of consistent API.
    - deleted 11y ago
      [deleted]
- 4ad 11y ago
  > You can't 'ls' your network connections. You sure can in Plan 9. Unfortunately (?) Plan 9 is more Unix than Unix itself.

mikeash 11y ago

Sometimes people run rm -rf / just for fun before reformatting a system, just to see what happens. Given that its purpose in life is to delete files, it stands to reason that running this command on a system which contains no important data is OK. A default configuration which makes this command destroy hardware is not reasonable.

kbenson 11y ago
rm -rf / probably doesn't do what you think it does. The coreutils version of rm includes --preserve-root[1], which is the default[2]. It also supports --one-file-system, which would prevent this and a host of other problems as well. That said, I don't really see a problem with Lennart's response. It's basically, "we should take steps to make this hard to do, but root is capable of doing anything, so don't expect it to be foolproof." 1: https://www.gnu.org/software/coreutils/manual/html_node/rm-invocation.html https://www.gnu.org/software/coreutils/manual/html_node/rm-i... 2: https://www.gnu.org/software/coreutils/manual/html_node/Treating-_002f-specially.html#Treating-_002f-specially https://www.gnu.org/software/coreutils/manual/html_node/Trea...
- mikeash 11y ago
  Is there some response besides the one linked here? Because all I see here is basically saying, "We're not going to change anything, this is not a problem, remount it yourself if you don't like it."
  - kbenson 11y ago
    He says "The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root." That looks like agreement that it needs something done to me. I took the followup comment to be a useful to on how to mitigate the problem until then.
    - mikeash 11y ago
      Isn't it already only writeable by root? The request is to make it not even writeable by root without taking some additional action to make it writeable first. If I understand correctly, that bit you quote just describes the current situation.

krylon 11y ago

> Systemd hate is en vogue these days To be fair, Lennart Poettering could probably end war and famine forever in a single day, and some people would still find something wrong with that. On the other hand a certain amount of skepticism and criticism is very much in order. (I am saddened, though, by the way online discussions so easily deteriorate into name-calling and bitter ranting.) Just to be clear, I was highly skeptical of systemd initially, now I have two systems running Debian Jessie, and quite honestly I haven't noticed much of a difference one way or the other. So at least now I am more confident that we are not all going to die because of systemd. On the other hand, I wish there had been more initial coordination / portability work to make sure stuff like GNOME keeps working smoothly on *BSD as well.

bigbugbag 11y ago
On the other hand I was happy and welcoming of systemd then I started to experience way too many breakage due to attitude of the devs. When you have to spend 2 days to get to a remote server room and back because suddenly systemd decided that a device in fstab not present at boot would halt boot with error and at the same time the emergency shell was broken and going into a loop of asking for credentials, on a debian server, in production. Ok systemd works most of the time but after experiencing a few of these breakages I've become wary of anything systemd. Whatever it brings to the table is not worth the wasted time and headaches it causes.
- krylon 11y ago
  Oh my, that is bad indeed. Apart from the two-item sample of personal experience I am kind of torn about systemd - some of the problems it attempts to address are real, and addressing these in general seems like a good idea. The way it does so, however, sometimes (I am being deliberately vague here) brings along some problems of its own.[1] And the further systemd adoption and systemd's mission creep go along, the harder it becomes to backtrack and replace it in case somebody comes up with a better solution. [1] Like I said, I have not experienced any of these problems myself, but I have read a couple of reports from people that had problems with systemd that were definitely not just aesthetic.

bigbugbag 11y ago

This is not what actually happened when this was reported on arch linux forums: https://bbs.archlinux.org/viewtopic.php?id=207549 https://bbs.archlinux.org/viewtopic.php?id=207549