56

Is the default Ctrl-Alt-Delete shutdown -r functionality on Linux systems a dangerous feature?

Years ago, when I deployed physical systems with attached keyboards and monitors, I'd sometimes modify the /etc/inittab on Red Hat systems to disable the reboot trap. This usually happened after a local IT person or Windows admin accidentally used the magic key combination on the wrong terminal/keyboard/window and rebooted their server.

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

I haven't done this since the RHEL4 days, but newer systems seem to have a /etc/init/control-alt-delete.conf file for this.

In the years since, most of my systems have been deployed headless or are running as virtual machines. This has reduced the frequency of unintended reboots... however, I've had a recent set of ctrl-alt-delete oopses from:

1). an IP KVM plugged into the wrong server by datacenter staff.
2). a Windows admin using the key combination in a VMware console, thinking it was needed for logon.
3). me using the ctrl-alt-delete macro in an HP ILO console to reboot a live CD... but it was actually the ILO for a very busy production server.

enter image description here

  • Does it make sense to disable Ctrl-Alt-Delete reboot in Linux by default?
  • Is this a common concern, or generally ignored?
  • Are there any downsides to doing so?
  • How do you handle this in your environment?

Edit: In fact, I just encountered this server, a virtual machine running for 1,115 days, root password unknown, and VMware tools were not installed (so Ctrl-Alt-Delete would be the only graceful shutdown option).

ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 8
    No, because if you can't reboot an arbitrary computer in your network you have bigger problems. See, e.g., the Chaos Monkey. – dmourati Jul 21 '14 at 03:22
  • 15
    @dmourati That's untrue. *Real world* line-of-business systems [don't always run like web scale applications](http://serverfault.com/a/607991/13325). It's irresponsible to suggest that's an architectural failing. – ewwhite Jul 21 '14 at 03:35
  • 8
    Even if you *could* reboot an arbitrary system, you wouldn't want to. In a real world IT scenario, you would only want to have *planned* reboots when *necessary*. Oopsies are always bad, and should be avoided, and this question is all about the oopsies. – Journeyman Geek Jul 21 '14 at 05:25
  • @dmourati What does one has to do with the other? you can achieve better arbitrary reboot scenarios using ipmi than any kind of orderly in-system shutdown command. Beside the fact that in most production environments you wouldn't want to. Economics drive the business, and reducing resources on purpose arbitrarily is not what profits make. – Dani_l Jul 21 '14 at 06:27
  • 1
    I disable it on all my VMs, because most hypervisors can do a safe shutdown via their tools/modules. AFAIK the is no reason for it all in a VM. – Zoredache Jul 21 '14 at 06:33
  • 1
    what is "so dangerous" about issuing a `shutdown -r` command to the system? this should shutdown and reboot gracefully the machine, no? – fduff Jul 21 '14 at 09:45
  • 6
    @fduff In the case of the production system I rebooted this weekend, it caused about 13 minutes of downtime because the server takes a long time to POST, plus the application did not go down cleanly (it's not controlled via init scripts), which let to ~45 minutes of database repair following the reboot. – ewwhite Jul 21 '14 at 09:52
  • 1
    Isn't the real problem that people are regularly misidentifying machines? – JamesRyan Jul 21 '14 at 13:56
  • 6
    @JamesRyan Maybe. But not always. If Windows users/administrators are conditioned to use Ctrl-Alt-Delete to wake a screen or authenticate, it's an understandable mistake. In the ILO/IPMI/KVM situations, yes, more care could be taken to identify systems, but that's not always possible... (*e.g. relying on remote hands at a data center*) – ewwhite Jul 21 '14 at 13:59
  • sysrq serves the same (and more) purposes and isn't as easily accidentally touched. I use that instead. – PlasmaHH Jul 22 '14 at 08:00
  • I've had the opposite problem once. I was logged on remotely to a server from a desktop machine, and wanted to reboot the desktop machine. I typed `shutdown -r now` only to realise, I was in the wrong window or forgot to log out from the server first... I wish I had used Ctrl+Alt+Del. (Of course, this doesn't necessarily apply to your case, since you seem to be concerned with disabling it on servers.) – Bruno Jul 22 '14 at 13:29
  • @ewwhite Windows administrator conditioning is a good enough reason in itself if you run a mixed environment. – Paul Gear Jul 22 '14 at 21:39
  • @ewwhite : [It depends](http://man7.org/linux/man-pages/man8/ctrlaltdel.8.html)... :) – user2284570 Jul 23 '14 at 01:12
  • @fduff : Maybe because it can be [configured to trigger an immediate reset](http://man7.org/linux/man-pages/man8/ctrlaltdel.8.html)? – user2284570 Jul 23 '14 at 08:29

3 Answers3

37

This can be useful for very, very seldom touched machines. Years after installation, if no-one can remember a login for the host, Ctrl-Alt-Delete will do proper shutdown and then let you use GRUB (or even LiLo!) to supply rw init=/bin/bash to the kernel and thus give you the chance to reset the root password.

The above is also a way that Ctrl-Alt-Delete is dangerous even if physical access to the power/reset switches and power cables is prevented. A boot loader password (and BIOS password plus disabling of USB/CD-ROM boot and the boot menu key) can prevent this but makes legitimate emergency recovery more difficult.

Alastair Irvine
  • 1,172
  • 10
  • 22
  • 3
    You're right. I *have* used this feature this way in the situation you described. – ewwhite Jul 21 '14 at 04:25
  • Even then it's easier to load a "rescue" media, mount, and enter the hash of a known password. Over IPMI you load the media from an iso file, making the entire "physical access" issue moot. Or you load from a special configuration tftp/pxe, after enabling boot from net. – Dani_l Jul 21 '14 at 06:16
  • I believe what I mentioned about BIOS password & options still applies when using IPMI. I'd be pleased to hear if that's incorrect. – Alastair Irvine Jul 21 '14 at 06:47
  • 1
    I disagree about rescue media. It's not hard to remember the kernel options that I mentioned. Your method requires optical media (or an ISO file under IPMI) and a password hash, which has to be typed in or copied from USB storage. (If you downvoted, please undo.) – Alastair Irvine Jul 21 '14 at 06:49
  • This has my vote. I last had occasion to lawfully use CAD reboot on Saturday, in a colo in Stevenage; I was glad it was an option. The real issue is that physical access to machines by idiots and/or the malicious can be harmful, and **that's** what should be minimised. – MadHatter Jul 21 '14 at 07:26
  • 1
    @AlastairIrvine I didn't downvote, and you are correct about ipmi - an ipmi console will give you access to machine console during entire boot process, including entering bios so you will face same issues. Not to mention that self respecting server HW should have ability to facilitate parameter change from running OS (e.g IBM's ASU https://www.ibm.com/support/entry/myportal/docdisplay?lndocid=TOOL-ASU). – Dani_l Jul 21 '14 at 10:36
  • In Any event, the argument here is - "very, very seldom touched machines". I don't see such one-offs as a sufficient basis for a day-to-day policy. In such cases take the extra time to do whatever. It should not dictate your production environment. – Dani_l Jul 21 '14 at 10:42
  • Well, I've concluded that I'll disable it conditionally... maybe write a puppet module to control this. – ewwhite Jul 24 '14 at 22:01
7

If you have ILO/IPMI/... It makes absolute sense. The only reason for CTRLALTDEL was a magic trap when nothing else would interrupt. With a control card, you don't need that - you can reset the machine anyway. Needless to say, if the machine behaves correctly, you can always 'reboot'/'shutdown -r now'/'init 6'/'systemctl reboot' from console or gui.

Dani_l
  • 498
  • 2
  • 8
4

I feel that the chances of accidental reboot via ctrl-alt-delete are much greater than the chances of a server's root password being forgotten, and therefore in production environments it makes sense to disable ctrl-alt-delete. I personally do this on my production systems.

The chances of a hard powercycle on a running linux host causing unrecoverable data corruption is small. In the hundreds of times I've done this over the years, I can't recall a single instance where the system wasn't able to fix itself (fsck) on boot. So I consider this a valid option on hosts where the root password is unknown, barring the availability of other methods for graceful shutdown.

Michael Martinez
  • 2,543
  • 3
  • 20
  • 31
  • 1
    How do you disable the ctrl-alt-delete option in the VM machine hosted on the Esx Server? – kvivek Jul 24 '15 at 08:59