1. Overview

Power management is an essential aspect of Linux systems administration. The poweroff and reboot commands are two of the most commonly used commands for shutting down or restarting a Linux system. However, by default, we can only execute these commands with root privileges.

In this tutorial, we’ll discuss how the poweroff and reboot commands work. Then, we’ll investigate how to grant shutdown and reboot permissions to normal users.

2. poweroff and reboot Commands

The poweroff and reboot commands are part of the systemd system and service manager.

By default, poweroff and reboot are located in the /sbin/ directory, which is not accessible to normal users.

The poweroff command sends an ACPI signal to the hardware. This instructs the system to power down completely.

Conversely, the reboot command instructs the system to restart. This involves the system shutting down and then booting up again.

Both commands have options that modify their behavior:

  • -f – force the power-off or reboot action
  • –halt – halt the system instead of powering off or rebooting
  • –reboot – reboot the system, regardless of the command used
  • -p – power off the system instead of halting or rebooting

For example, we can power off the system with the reboot command and the -p flag:

$ sudo reboot -p

The -p option tells the command to power off the system instead of rebooting.

Additionally, we can force an immediate power-off or reboot using the -f option:

$ sudo poweroff -f

The -f option causes an immediate but clean shutdown by the system manager.

Notably, when the -f option is specified twice, this causes an immediate shutdown:

$ sudo poweroff -ff

This command results in an immediate shutdown without contacting the system manager, systemd.

Also, we can use the –halt option to halt the system without rebooting it:

$ sudo reboot --halt

This is equivalent to using the halt command.

3. Limitations of Normal Users

The permissions and access of files and directories are determined by the filesystem. The filesystem assigns three types of permissions to each file:

  • read
  • write
  • execute

Also, the filesystem assigns three types of users to each file and directory:

  • owner
  • group
  • others

Therefore, the permissions and access of poweroff and reboot commands are also determined by the filesystem. By default, these commands are located in /sbin/, which is a directory that contains system administration commands. The permissions and access of /sbin/ are usually set as:

  • owner – root has read, write, and execute permissions
  • group – root has read and execute permissions
  • others – read and execute permissions

This means that only root can modify or delete the files and directories in /sbin/, while other users can only read or execute them. However, normal users can’t run them even if they have execute permission. Therefore, normal users need to use other methods to run poweroff and reboot commands.

The reasons behind these restrictions are mainly related to security and system stability. poweroff and reboot are powerful commands that can affect the whole system state. If normal users could run these commands without any restriction or authentication, the commands would bring some unwanted risks.

In general, if all users could shut down the system, this may result in data loss, as well as interruption of service for everyone else.

As Linux is designed as a multi-user system, it’s usually imperative to prevent most users from having the capability to power off the system while others are actively using it.

4. Granting Shutdown and Reboot Permissions

When we’re working on a GUI-less server, or we want to power off or reboot our system as part of a script or a cron job, we may need to run poweroff and reboot as a normal user. Let’s discuss some methods we can use to grant shutdown and reboot permissions to normal users.

4.1. The /etc/sudoers File

The /etc/sudoers file is a configuration file that defines the rules and settings for the sudo command. This file can specify which users can run which commands. Also, it can specify whether they need a password or not.

We can modify the /etc/sudoers file to allow normal users to execute poweroff and reboot commands without a password:

baeldung ALL = NOPASSWD: /sbin/poweroff, /sbin/reboot

In the code snippet above, baeldung is our username. Adding the line above will let us run sudo poweroff and sudo reboot without being asked for a password.

Modifying /etc/sudoers provides granularity and specificity over the permissions and privileges of poweroff and reboot for different users or groups. However, editing a sensitive file like this is risky. Thus, it may compromise the security or availability of the system.

4.2. Setuid Programs

Setuid programs have a special permission bit that allows them to run as the owner of the file, regardless of who executes them.

We can use setuid programs to run poweroff and reboot as a normal user by changing the owner and the permission of these commands:

$ sudo chown root /sbin/poweroff
$ sudo chmod u+s /sbin/poweroff
$ poweroff

First, we changed the owner of poweroff to root. Then, we set the setuid bit for poweroff. Finally, we ran the poweroff command as a normal user.

Although this approach is quite straightforward, it may pose some security risks or system stability. Also, setuid may reset after some system updates.

4.3. systemctl Permission and Ownership

systemctl is a program that controls the systemd system and service manager. It’s responsible for managing power management commands in some Linux systems. systemctl can be used to run poweroff and reboot and other systemctl operations.

Therefore, we can change the ownership and permission of systemctl to allow a specific user or group to execute it as a root user:

$ sudo chown root:root /bin/systemctl
$ sudo chmod 4755 /bin/systemctl
$ poweroff

First, we changed the owner and group of /bin/systemctl to root and root, respectively. Then, we set the setuid bit and the execute permission for /bin/systemctl. Finally, we ran the poweroff command as a normal user.

One advantage of this is that it provides access to all systemctl operations. This may be useful for embedded systems or other scenarios where the user needs to work with system services. However, it may compromise the security of the system if we allow normal users to execute all systemctl operations without any restriction.

Notably, we can use the groups command to display the groups a user belongs to:

$ groups root
root : root

This shows that root belongs to the root group.

5. systemd and polkit

On systems with systemd as the init system, a user on the terminal can shut down and reboot without root privileges. For instance, with systemd and an active logind session, we can reboot or power off without elevated privileges, provided that no other user is still logged in.

Some systems use systemd by default:

  • Ubuntu (since version 15.04)
  • Debian (since version 8)
  • Fedora (since version 15)
  • CentOS (since version 7)
  • Arch Linux (since October 2012)

We can also check if our system uses systemd:

$ ps -p 1 -o comm=

The output will be systemd if our system uses systemd as the init system.

This is based on the assumption that if there’s only one user session active, then the user has physical access to the power button and can perform these actions anyway.

Notably, both poweroff and reboot commands are symbolic links to another command called systemctl.

However, if we have polkit, we can execute the shutdown, poweroff, and reboot commands without the root password if we’re the only local user online on the system.

6. Conclusion

In this article, we’ve discussed how to run poweroff and reboot as a normal user in Linux systems. We discussed the default restrictions imposed on normal users for executing these commands. Furthermore, we explored the reason behind these limitations from a security and system stability perspective.

Finally, we investigated different methods we can use to grant shutdown and reboot permissions to normal users.

However, we should be cautious when changing the permissions or privileges of poweroff or reboot as they may affect security or system stability.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.