Steve Litt <slitt@???> writes:
> On Fri, 5 Feb 2016 18:33:44 +0100 Didier Kryn <kryn@???> wrote:
>

>>      People have always expected rm -rf / to destroy the OS. They
>> also know that, from the keyboard, with root priviledge, they can
>> destroy the partition table of the disk. All this is repairable by
>> the admin her/himself.

>>

>>      The ability to brick the motherboard is brand new. 

>
> Not only brand new, but an entirely new level of consequence.
>
> With excellent backups, rm -rf / or even dd if=/dev/zero of=/dev/sda1 is
> correctable with a few hours of work, on the premises, with only
> resources on the premises.

A somewhat seriously wrong conception about the relation between / (the
root of the filesystem name tree) and /dev/sda1 (some partition of a
mass storage device) seems to exist here. The reality is "there is none"
unless the system happens to be configured such that /dev/sda1 is
mounted as / and nothing else has been integrated into the filesystem
namespace. But usually, this won't be the case and a number of devices/
partitions and virtual filesystems providing various features will
collectively provide 'named objects' which can be manipulated using the
filesystem API. The current list can be displayed with

cat /proc/mounts

,----
| For historical reasons, the mount command also maintains a list of
| mounted filesystems in the file /etc/mtab which it displays when
| executed without arguments. But the current /etc/mtab doesn't
| necessarily reflect reality, eg, because / is mounted r/o or because the
| current / came into being via chroot.
`----

Each of the mounted filesystems provides a set of methods implementing
the filesystem syscalls for this kind of filesystem and there are no
restriction regarding what these method might do. Eg, one could create a
filesystem where deleting a file named Richard causes an immediate
ACPI poweroff. There's also a Filesystem In Userspace (FUSE) facility
which enables arbitrary applications to implement filesystem syscalls.

"Invoke unlink/ rmdir methods for all named objects currently visible in
the filesystem namespace" is something very much different from
"fill a disk partition with zeroes" and doing this without knowing what
these unlink/ rmdir methods will end up doing is just recklessly trying
one's luck.