How to protect potentially destructive command line options?

Question

I'm curious if anyone can help me with what the best way to protect potentially destructive command line options is for a linux command line application?

To give a very hypothetical scenario: imagine a command line program that sets the maximum thermal setting for a processor before emergency power off. Lets further pretend that there are two main options, one of which is --max-temperature (in Celsius), which can be set to any integer between 30 & 50. There is also an override flag --melt which would disable the processor from shutting down via software regardless of how hot the processor got, until the system electrically/mechanically failed.

Certainly such an option like --melt is dangerous, and could cause physical destruction at worst case. But again, lets pretend that this type of functionality is a requirement (albeit a strange one). The application has to run as root, but if there was a desire to help ensure the --melt option wasn't accidentally triggered by confused, or not experience users how would you do that?

Certainly a very common anti-pattern (IMO) is to hide the option, so that --help or the man page doesn't reveal its existence, but that is security through obscurity and could have the unintended consequence of a user triggering it, but not being able to find out what it means.

Another possibility is to change the flag to a command line argument that requires the user to pass --melt OVERRIDE, or some other token as a signifier that they REALLY mean to do this.

Are there other mechanisms to accomplish the same goal?

Answer 1

I'm assuming you're looking at this from the POV of the utility programmer. This is broad enough that there isn't (and can't be) a single right answer, but some things come to mind.

I think most utilities just have a single "force" flag (-f), that overrides most safety checks. On the other hand, e.g. dpkg has a more fine-grained --force-things switch, where things can be a number of different keywords.

And apt-get makes you write a complete sentence to verify in some cases, like removing "essential" packages. See below. (I think it's not just a command line option here, since essential packages are e.g. those that are required to install packages, so undoing a mistaken action may be very hard. Besides, the whole operation may not be known up front, before apt has had a chance to calculate the package dependencies.)

Then, I think cdrecord used to make the user wait a couple of seconds before actually starting the work, so that you had a chance to verify the settings were sane while the numbers were running down.

---

Here's what you get if you try to apt-get remove bash:

WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  bash
0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
After this operation, 2,870 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] ^C

---

Which one to choose is up to you as the program author - you'll have to base the decision on the danger level of the action, and on your own level of paranoia. (Be it based on caring about your users, or on the fear of getting blamed for the mess.)

Something that has the potential to cause the processor to literally (halt and) catch fire probably goes in the high end of the "danger" axis and probably warrants something like the "type 'Yes, do what I say'" treatment.

---

That said, one thing to realise is that many of the actual kernel-level interfaces are not protected by any means. Instead, there are files under /sys that can change things just by being opened and written to, no questions asked apart from the file access permissions. (i.e. you need to be root.)

This goes for hard drive contents too (as we should know), and, in one case two years back, to the configuration variables of the motherboard firmware. It seems it was possible to "brick" computers with a misplaced rm -rf.

No, really. See lwn.net article and the systemd issue tracker.

So, whatever protections you would implement, you would only protect the actions done using that particular tool.