CentOS Linux by default allows all users to have permission to "halt" & "reboot" the system by using the commands halt and reboot.

How can I configure my system so that only the root user has the right to halt/reboot the system?

  • Remove SUID-bit from halt and reboot.
    – Eddy_Em
    Jun 24, 2013 at 13:15
  • Don't remove the suid bit, otherwise a normal user logged in at the console can't reboot the system. Leave the permissions as they are. The programs already have logic to let only the superuser or the console user run these commands successfully.
    – John
    Jun 24, 2013 at 13:35

2 Answers 2



You can disable access to these commands by removing their entries in the /etc/security/console.apps/*:

$ $ ls /etc/security/console.apps/
authconfig      gparted          poweroff                      system-config-date      system-config-network-cmd  zenmap-root
authconfig-gtk  halt             reboot                        system-config-keyboard  system-config-selinux
authconfig-tui  kismet_capture   setup                         system-config-language  system-config-users
chkrootkit      liveusb-creator  system-config-authentication  system-config-lvm       wifi-radar
config-util     lshw-gui         system-config-boot            system-config-network   wireshark

$ rm -f /etc/security/console.apps/reboot

Above was found here: 27.2. Disabling Console Program Access - CentOS Deployment Guide

Hack method

I think you can achieve this by doing the following. In the directory /lib/upstart, are the following commands:

$ pwd

$ ls -la
total 176
drwxr-xr-x.  2 root root  4096 Sep  9  2011 .
dr-xr-xr-x. 16 root root 12288 May  4 21:27 ..
lrwxrwxrwx   1 root root     6 May 26  2011 halt -> reboot
lrwxrwxrwx   1 root root     6 May 26  2011 poweroff -> reboot
-rwxr-xr-x   1 root root 17112 May 11  2011 reboot
-rwxr-xr-x   1 root root 14472 May 11  2011 runlevel
-rwxr-xr-x   1 root root 65976 May 11  2011 shutdown
-rwxr-xr-x   1 root root 56304 May 11  2011 telinit

chmod 700 the reboot executable:

$ chmod 700 /lib/upstart/reboot
  • 1
    You don't really ever want to change modes of system files like this.
    – John
    Jun 24, 2013 at 13:32
  • 2
    Why not? Show me a source that says this!
    – slm
    Jun 24, 2013 at 13:33
  • 2
    @John I do that all the time. One big example is that I remove world execute from su. It's important to verify that various changes don't break anything, but this would only break something if a core system script was both running as non-root (unlikely) and called the reboot binary directly (also unlikely). I haven't tested this specific change but "don't change modes on system files" isn't a valid general principle in my experience.
    – Bratchley
    Jun 24, 2013 at 13:37
  • 1
    See my updates, there is the "official" way to to remove the commands from access for the users.
    – slm
    Jun 24, 2013 at 13:42
  • 1
    Not all warnings need to be acted upon. There is such a thing as expected failures. Making file permissions more restrictive is a core part of OS hardening. Generally, there's some mechanism for dealing with OS updates. Where I work, I have a cronjob that runs every five minutes that issues appropriate setfacl and chmod commands (in case someone manually makes permissions more liberal and doesn't reset them) other places use IDS tools like Tripwire to ensure continued compliance.
    – Bratchley
    Jun 24, 2013 at 13:56

These commands already force you to either be root or be logged in to the console. If a normal user runs "halt" or "reboot" from an ssh session, it refuses to halt or reboot the system:

$ halt
halt: must be superuser.

  • Reboot doesn't! I use that all the time as a non-root user on my laptop!
    – slm
    Jun 24, 2013 at 13:38
  • And you're logged in tot he console of your laptop when you issue that command, so you should be able to issue that command. When SSH'ed in to a system as a non-root user, if you issue the reboot command, you will be told "reboot: must be superuser."
    – John
    Jun 24, 2013 at 13:40
  • The requirement in the OP is that only the root user can initiate a reboot. System defaults leave open the possibility that non-root users can execute if they have CAP_SYS_BOOT. Your user likely doesn't have that capability configured for it so that's why it's erroring out ("must be superuser" is just a helpful message given how most platforms are set up by default).
    – Bratchley
    Jun 24, 2013 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.