6

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.

Improve this question
4
  • One example is removing LUKS encryption in-place. That involves writing to a disk which is currently in use by LUKS. Maybe what you really wanted to know was, 'how can I make sure a device is not in use by anything before I write to it' or the like... Commented Oct 18, 2014 at 12:55
  • What are you using dd a lot for? Could you not write a wrapper script for those tasks that didn't require to enter the destination verbatim? Commented Oct 18, 2014 at 14:20
  • 1
    What you want to do is essentially to reformat the SD card, which should require superuser powers (otherwise you might accidentially ruin your media). Perhaps the actual problem is that you need to run the raw commands a lot, instead of using a script or full blown program to help you? Commented Oct 18, 2014 at 16:18
  • 4
    If you are using Debian, or dervied like Ubuntu, work from /dev/disk/by-id instead of the device names in /dev. Commented Oct 18, 2014 at 17:28

3 Answers 3

Reset to default
11

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.

Consider the kinds of power tools used in civil construction and what you can screw up by doing one little thing wrong. Could those things be made more preventable? Probably, but the counter balance is to what extent making accidents more preventable makes the tool less useful and/or more awkward.

Driving automobiles is a similar analogy with potentially much more dire consequences, and yet human beings manage to do this all the time (much too much, in fact). Of course it would be safer if they did it slower, but collectively we have decide what risks are worth taking. Similarly, the computer would be safer if dd did not exist, but since its usefulness is considered to outweigh its risks, it does.

Why ins't there a security measure that prevent dd from writing on the disk it gets the command from ?

In fact there is, since by default device files (such as /dev/sda1) need superuser privileges to write to. So unless you are working as root or via sudo, you actually cannot screw your entire computer with one button using dd.

Which brings us to why there are all the caveats about running commands with superuser privileges. These warnings are very prevalent and I think it would be hard to end up operating a *nix system without having seen them, sort of like getting into a construction zone without noticing the HARD HAT AREA signs.

If you don't have a reason to be in a construction zone, leave. If you do, take appropriate safety precautions. The world can be a dangerous place and some places more dangerous than others. Don't act without thinking. A degree of safety which ensures nothing bad can happen -- so you don't have to bother thinking -- implies you can't do much either. Sometimes that's desirable, sometimes it is not.

Improve this answer
5
  • All the distros I've used ask for root privileges to write on a SD card. I'm not talking about removing this function from dd, but maybe add a little step, like an option or confirmation message, to prevent erasing all your data, since it might be far from what the vast majority of users want. To go on your automobiles analogy, it seems to me that it's like having a "disable breaks" button on your dashboard you can hit unintentionally. Commented Oct 18, 2014 at 13:13
  • I think I've heard someone suggest something similar before; I guess what is at issue is the perspective of the people who design and implement such tools. As a rule of thumb, if you are uncertain about how something works or worried about what it can do, proceed with caution (and of course, always have your important data securely backed up). If you are regularly making mistakes that require you to, e.g., re-install the system, you are not cautious enough. WRT the "disable brakes" analogy, I think the feature you are talking about would be more like things that beep when you are... Commented Oct 18, 2014 at 13:40
  • ...in too close proximity to something (e.g., while reversing), or visibly warn you when your stopping distance has become too close to infeasible (preventing frontal collisions). As is, dd has brakes, just you are expected to know when and how to use them, as in a car. You have to learn to use a car, and the command line. The reason you don't have to have a licence to do the later is not because it is easier, but because it is not dangerous in the same way, particularly to others. Commented Oct 18, 2014 at 13:43
  • 4
    "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things" Commented Oct 18, 2014 at 18:22
  • Again, not talking about stopping, but warning. Commented Oct 18, 2014 at 19:56
6

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.

Improve this answer
2
  • Thanks, that seems a way better answer than "you just need to be careful". Commented Oct 18, 2014 at 16:43
  • 2
    They still could add an option like --check-before-writing, which would be completely backwards compatible if disabled by default. Commented Oct 19, 2014 at 5:53
0

To "add a little step, like an option or confirmation message", you can do what artm suggested in the comments to your question: use a wrapper script.

In other words, rather than dealing directly with the somewhat daunting command line arguments of dd directly, create a script in bash (or Python, etc) that takes the dd arguments that you're interested in, using an option syntax that you're more comfortable with. The script checks that the arguments are sensible, and prints out the arguments (and possibly the final dd command line) so you can verify that everything is as it should be. And then the script asks you "OK to proceed? [y/N]" so you have to enter y if you want the script to actually run the dd command line it's constructed for you.

So if you never want the script to write to /dev/sda or its partitions you can make it impossible for it to do so. To help you verify that you have actuallyselected the input and output devices you meant to, the script could use the blkid command to get the UUID and disk label for those devices. Etc.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.