Linux reboot no root

Why does reboot and poweroff require root privileges? [duplicate]

To restart or shut off Linux from the terminal, one can use reboot and poweroff , respectively. However, both of these commands require root privileges. Why is this so? What security risk is posed by not requiring this to have root privileges? The GUI provides a way for any user to shut off or restart, so why do the terminal commands need to be run as root? Speaking of the options from the GUI, if the terminal requires root privileges to shut off or restart the Linux computer, how is the GUI able to present an option that does the same without requiring the entering of a password?

If that’s what you are looking for, it is possible to give more permissions to the user logged in via the local terminals — look up pam_console .

btw, for those interested: gnome-session-quit —poweroff —force will shut you down without being root.

On modern systems with systemd , a user on the terminal can shutdown and reboot without root privileges, using the commands systemctl poweroff and systemctl reboot . This will ask for authentication using polkit if you’re on a remote login or your policy otherwise requires it, but otherwise doesn’t require any special privilege.

6 Answers 6

Warning: by the end of this answer you’ll probably know more about linux than you wanted to

Why reboot and poweroff require root privileges

GNU/Linux operating systems are multi-user, as were its UNIX predecessors. The system is a shared resource, and multiple users can use it simultaneously.

In the past this usually happened on computer terminals connected to a minicomputer or a mainframe.

The popular PDP-11 minicomputer. A bit large, by today’s standards 🙂

In modern days, this can happen either remotely over the network (usually via SSH), on thin clients or on a multiseat configuration, where there are several local users with hardware attached to the same computer.

A multi-seat configuration. Photo by Tiago Vignatti

In practice, there can be hundreds or thousands of users using the same computer simultaneously. It wouldn’t make much sense if any user could power off the computer, and prevent everyone else from using it.

What security risk is posed by not requiring this to have root privileges?

On a multi-user system, this prevents what is effectively a denial-of-service attack

The GUI provides a way for any user to shut off or restart, so why do the terminal commands need to be run as root?

Many Linux distributions do not provide a GUI. The desktop Linux distributions that do are usually oriented to a single user pattern, so it makes sense to allow this from the GUI.

Possible reasons why the commands still require root privileges:

• Most users of a desktop-oriented distro will use the GUI, not the command line, so it’s not worth the trouble
• Consistency with accepted UNIX conventions
• (Arguably misguided) security, as it prevents naive programs or scripts from powering off the system

How is the GUI able to present shutdown without root privileges?

The actual mechanism will vary depending on the specific desktop manager (GUI). Generally speaking, there are several mechanisms available for this type of task:

• Running the GUI itself as root (hopefully that shouldn’t happen on any proper implementation. )
• setuid
• sudo with NOPASSWD
• Communicating the command to another process that has those privileges, usually done with D-Bus. On popular GUIs, this is usually managed by polkit.

In summary

Linux is used in very diverse environments — from mainframes, servers and desktops to supercomputers, mobile phones, and microwave ovens. It’s hard to keep everyone happy all the time! 🙂

@Peter With any luck you’re in the sudo’ers list and aren’t actually needing to login as root to shut down. If all else fails, pull the cable. Alternatively, you can use eggs.

If you’re physically at a workstation to operate the GUI, then you also have access to the power switch, so not providing the shutdown/reboot option does not really prevent you from shutting it down. If you had to just turn it off without a proper shutdown, you’d do more damage. Therefore including shutdown/reboot for local GUI is a win.

I think all GUIs nowadays do it with the last option, communicating over D-Bus (to polkitd). You probably want to explain this somewhat—as its also how you’d change that behavior.

@MontyHarder: most power switch actually sends ACPI command; which do shutdown the computer. Usually you’ll need to hold it for around 5 second for it to cut off power.

Linux has its origins in Unix and Unix was initially developed as a multi-user operating system. You could have one user disrupt other users by wanting to reboot the system. Only the administrator with root privileges could do that.

Worth noting is that you could expand the «disrupted users» to those consuming the services running on the machine (databases, web services in particular).

The underlying assumption is that a system with a local GUI installed tends to not be used as a multiuser host. A server will rarely have a running display manager, if anyone needs to execute GUI tools on it they can do so via remote X11. With many display managers (which themselves are usually running with root permissions), if you get a remote session via XDMCP the shutdown/reboot buttons will be disabled. Also, many desktop linux systems will check if any other user is logged in when a non-root user triggers such an action, and will refuse to reboot/shutdown if that is the case.

Its quite natural and a policy matter and convenience, it had been allowed from GUI because you are physically logged in to the machine. ( Some Linux distributions will still ask you for password if the GUI is not running as root , I am using Centos 6 and there is even no GUI shutdown/reboot option for my user , there is only log out and lock option)

From a pseudo-terminal you need to be root or have the sudo privilege because you might not want any user to ssh into your server or machine and shut it down or reboot it.

X11 works over the network, so a GUI user might not be physically present next to the machine (presumably what you meant by «physically logged in»). In a thin client setup, many users may be running GUIs from one machine; allowing all of them to shutdown/reboot would be a bad idea.

Thin client is a different thing , only the instance of that user will get shutdown from GUI not other users , each user has his own VM.

But by your policy you can make sure that GUI only means physically present. Disable X11 forwarding and disable ssh root login.

An X11-forwarding session does not have the root privileges an xdm has, so there is nothing you could run that is capable of rebooting the machine.

Shutdown (of any kind) affects all users, up to and including killing their processes. This is not something that you would normally want J. Random User to be able to do, simply because they are logged in.

Normally, only authorised operators should be allowed to reboot, and in some cases, those with physical access — many Linux systems can be shut down from a power button on the case. I know this, because I have accidentally done so! Nowadays, I normally leave the button disconnected when assembling a system.

Back in 1989, I was at a shop using A/UX on Macintoshes and was mostly impressed, except for the requirement that shutting down the machine even from the local keyboard required a root login (which was solved by giving all machines the same root password, which everybody knew!). How hard should it be to have a setuid script which if run from the local console will shut down the machine and otherwise do nothing? How hard is it to guard against console spoofing?

What security risk is posed by not requiring this to have root privileges? The GUI provides a way for any user to shut off or restart, so why do the terminal commands need to be run as root?

Yes, as said in this answer, Linux is inherently designed as multiuser system. Consider more than one user are working on a system, then it would be bad if any one normal user is allowed to turn-off the system while others are working. Imagine what happens if your web-server taken down by a user at a distance! So, Only system administrator aka root-user is allowed to poweroff or reboot the system.

$ which poweroff reboot /sbin/poweroff /sbin/reboot 

So, poweroff and reboot are located under /sbin directory which holds the utilities and root-only commands, essential binaries for booting, restoring, recovering, and/or repairing the system.

So, these commands are expected to be run by system-administrator/root user, visit the manpage:

DESCRIPTION These programs allow a system administrator to reboot, halt or poweroff the system. 

Speaking of the options from the GUI, if the terminal requires root privileges to shut off or restart the Linux computer, how is the GUI able to present an option that does the same without requiring the entering of a password?

GUI is a matter of convenience and obviously user logged into GUI, knows what’s going on and what s/he is doing. So, it doesn’t expect password prompt/requirement from user i.e allowed to be shut-down or reboot through some mechanism like policy-kit. But in case of command-line the things are quit different.

Of course, you can use equivalent command provided by Desktop-Environment. Example, for gnome , you can use: gnome-session-quit with appropriate option which doesn’t require root privileges.

This puts the cart before the horse. The files are in /sbin because they’re intended for use by administrators only. But the question is, why are they intended for use by administrators only? The answer to that is not «because they’re in /sbin».

as the others already wrote, a «normal» user should not be able to end other users processes or shut down a service (web server, mail server, . ) and that’s why super user rights are needed.

The GUI is able to shut down or reboot via the setuid mechanism https://en.wikipedia.org/wiki/Setuid. In simple words: the reboot command itself has root priviliges and you as normal user are allowed to execute reboot. Since you’re not allowed to manipulate the reboot executable (you have execution rights but no write permission) this does not provide a way to gain root rights over the machine.

And (again as the others wrote already) the GUI is assumed to be run physically at the machine, so it is a user computer and not a server, and you could (by unplugging the power) anyhow power down the computer, so why bother about root rights 😉 I’ve also seen GUIs, which check if other users are logged in (e.g. a root shell somewhere) and do not allow to shut down if other users are logged in.

EDIT: As corrected by Pandya, it’s policy-kit allowing you as normal user to reboot/shut down

Источник

How does gnome reboot without root privileges?

For example, capable(CAP_SYS_NICE) checks whether the caller has the ability to modify nice values of other processes. By default, the superuser possesses all capabilities and nonroot possesses none. For example, here is the reboot() system call. Note how its first step is ensuring that the calling process has the CAP_SYS_REBOOT . If that one conditional statement were removed, any process could reboot the system.

However, in my Debian Sid I can reboot my machine by using gnome or by executing /sbin/reboot without sudo or su. How is this possible? Maybe with systemctl?

ls -l /sbin/reboot lrwxrwxrwx 1 root root 14 Jun 28 04:23 /sbin/reboot -> /bin/systemctl 

[damian@xvz:~]$ groups damian sudo wireshark bumblebee 

[damian@xvz:~]$ ls -l /bin/systemctl -rwxr-xr-x 1 root root 626640 Jun 28 04:23 /bin/systemctl 

1 Answer 1

This is done via an authorization manager called polkit :

polkit provides an authorization API intended to be used by privileged programs (“MECHANISMS”) offering service to unprivileged programs (“SUBJECTS”) often through some form of inter-process communication mechanism.

With systemd and polkit users with non-remote session can issue power related commands. You can list all polkit registered actions and get details about any of them with pkaction (invoked with no arguments it will list all action ids).
In this particular case the action id is org.freedesktop.login1.reboot so if you run:

pkaction --action-id org.freedesktop.login1.reboot --verbose 

the output should be something like:

org.freedesktop.login1.reboot: description: Reboot the system message: Authentication is required for rebooting the system. vendor: The systemd Project vendor_url: http://www.freedesktop.org/wiki/Software/systemd icon: implicit any: auth_admin_keep implicit inactive: auth_admin_keep implicit active: yes 

Here, active: yes means the user in the active session is authorized to reboot the system (details about implicit authorizations on polkit page). You can check if your session is active with:

loginctl show-session $XDG_SESSION_ID --property=Active

Источник