Why dd Command is Not Protected Against Writing on Active Disk

block-devicedddiskpermissions

I use dd a lot. I live in a contant fear of making a mistake one day, for example writing on sda (computer disk) instead of sdb (USB disk) and then erasing everything I have on my computer.

I know dd is supposed to be a power user tool but still, it doesn't make sense to me that you can basically screw your whole computer by hitting the wrong key.

Why ins't there a security measure that prevent dd from writing on the disk it gets the command from ? Not sure how anyone would do this on purpose.

Please note that I didn't tried this myself, I've only read about it, so I could be wrong about all that.

Best Answer

It's reasonable to ask why the dd command doesn't first check whether its target contains a mounted filesystem, and then prompt for confirmation or require a special flag. One simple answer is that it would break any scripts that expect to be able to use dd in this way, and that aren't designed to handle interactive input. For instance, it can be reasonable to modify the partition table of a raw device while a partition of that same device is mounted; you just have to be careful to only modify the first sector.

There are a huge number of Linux systems out there in the wild, and it's impossible to know what kind of crazy setups people have come up with. So the maintainers of dd are very unlikely to make a backwards-incompatible change that would cause problems for an unknown number of environments.

Related Solutions

Linux – Why is dd reading from and writing to the same disk

If you specify a block size (512 bytes) of less than the block size of the disk (often 4096 bytes, but nowadays maybe more), the block will be partially written, so that the contents of the rest of the block must be preserved before writing.

This is because disk blocks cannot be written to with only 512 bytes, but you have to write a full block at once (4096 or larger). When you write this (4096) amount or more, there is no partial write, so it does not have to read.

Why does writing random data using dd result in disk partitions

Several possibilities:

Linux supports a lot of different partition table types, some of which use very few magic bytes, and then it's easy to mis-identify random data (*) [so it's possible to randomly generate a somewhat "valid" partition table].
Some partition table types have backups at the end of the disk as well (most notably GPT) and that could be picked up on if the start of the drive was replaced with random garbage.
The device doesn't work properly and it was disconnected before it finished writing the data, or keeps returning old data, so partition table survives. Sometimes this happens with USB sticks.
...

(*) Make 1000 files with random data in them and see what comes out:

$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP\011Secret Sub-key -
....

The goal of random-shredding a drive is to make old data vanish for good. There is no promise the drive will appear empty, unused, in pristine condition afterwards.

It's common to follow up with a zero wipe to achieve that. If you are using LVM, it's normal for LVM to zero out the first few sectors of any LV you create so old data won't interfere.

There's also a dedicated utility (wipefs) to get rid of old magic byte signatures which you can use to get rid of filesystem and partition table metadata.

Best Answer

Related Solutions

Linux – Why is dd reading from and writing to the same disk

Why does writing random data using dd result in disk partitions

Related Question