Steve Litt <[email protected]> writes: > On Fri, 5 Feb 2016 18:33:44 +0100 Didier Kryn <[email protected]> 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. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
