Linux: make shutdown not executable for safety

Question

Today I have shutdown'ed a production machine by mistake because I thought I was on my local machine. I know, novice mistake :-(

As a solution for it not to happen again, I was thinking to remove the execution permission for the shutdown command as that machine should be always on.

Is that a good idea? Can you see any unwanted side effect by doing that?

Cheers, Dan

Answer 1

Completely another aproach how to be warned that you work on productional machine is to mark the terminal. For example the user@machine:~# text could be red at production machines, green at development, etc. Here is nice tutorial how to do this: Color Bash Prompt

Answer 2

The best advice I can give you is don't login as root unless you need root access, and make sure you have a different root/sudo password on each machine.

Making shutdown inaccessible is one option but it's not a good one. Either alias shutdown to shutdown -a and touch /etc/shutdown.allow or chmod a-x /sbin/shutdown

Also, where does it end? Are you going to also disallow halt, reboot and init?

Answer 3

Some points to consider:

1. What were you doing as root on a production system during production time? Configure your systems so you don't have to be root on them for day-to-day work. You should never be root on a production system without a very good reason.
2. Learn the important lesson. When you are root you have to check twice before you press enter. SUDO is no protection if you just write your password to continue, without thinking. Prompt colouring, as mentioned by mkudlacek is a very useful tool to help ensure you are not on the wrong system.
3. Don't mess with the builtin tools. It is likely to break updates and will drive new hires insane. If you want to change something use your own alias file.

Answer 4

I don't think messing with the permissions on shutdown are the way to handle the situation. Basically you just learned a lesson. Chin up.

I've done the same kinds of things -- getting long chains of ssh sessions, then messing with the routes on one of the machines I was ssh'd through, cutting myself off. I've botched a rsync request, leading to a systematic destruction of a system on the other side of the world. I've run rm -rf / path on a production server. (That time I got to learn how the restores worked.)

So, much older and hopefully a little bit wiser, I now have strict rules I impose on myself.

• All root prompts end with a #, no matter what other information is in them.
• Any time I am at a # prompt, I literally sit on my hands before pressing the enter key.
• If there's any doubt about what I'm about to do or where I really am or how I got there, I cancel out of it and rebuild it again from a known start condition.
• When I make a mistake (and I still make them, although they are getting both less frequent and more obscure as time goes on), immediately figure out what I've done, who I've impacted, and go confess my sins to them. Then drop everything else and undo the damange as quickly and as best you can.

The nature of my job requires me to spend a lot of time at a lot of varied root prompts, but thanks to my errors in the past I maintain a far better situational awareness than I did when I started.

Answer 5

If you're using Ubuntu then try Molly-guard. As discussed in this similar question.

Answer 6

Depends, really. You could try just wrapping the command but it means that if you do updates or upgrades that affect that executable, you might forget about it and have it screw up an update. Playing with system shutdown commands can be a PITA, especially if you have new hires or a replacement that ends up not knowing you were playing with system binaries.

Personally I'd look at wrapping the command in a script that identifies the system by name and makes you confirm that's what you really want to do before running the actual binary, or that you have to type in a certain sequence of letters to confirm shutdown before it runs the binary. That should give some pause.

Answer 7

You might consider setting the command prompt to include the machine name, at least on servers. It just might help to prevent other commands being run on the wrong machine in the future. It's more effective if the machine names are coloured to make them stand out and you could even colour code to identify server roles.

Answer 8

One way is not to use su and/or login directly to root. Better to log into directly into the account AND have different password for root on local machine and ssh key.

Of course it is in addition to watching for red '#' prompt.

Answer 9

Yes, removing the execute bit on the shutdown command is the simplest and safest way of preventing accidental shutdowns, especially if you have a desktop environment like KDE on the machine and you want to prevent accidental shutdowns when logging out.

As for new people being confused, I think the first thing they'll do would be ls -l /sbin/shutdown to find out why it doesn't work (especially if they have the good habit of tab-completing executable names). Obviously though you should tell them about any changes you've made.

For extra safety you could add a line to /etc/rc.local to remove the execute bit from the shutdown command so you don't forget to reset it after a reboot.

Answer 10

you can just remove /sbin/ from root's path. that way you need to type the full path to execute it, and it usually fixes accidents.