70

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?

Pandya
  • 24,618
Rohan
  • 3,561
  • 2
    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. – chexum Jan 07 '16 at 08:46
  • 1
    btw, for those interested: gnome-session-quit --poweroff --force will shut you down without being root. – Naftuli Kay Jan 08 '16 at 09:32
  • 3
    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. – vurp0 Jan 11 '16 at 09:08

6 Answers6

71

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.

PDP-11

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.

multi-seat

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! :)

loopbackbee
  • 4,602
  • 36
    +1, but how do I shut down my microwave oven if I forgot the root password? – Peter Jan 08 '16 at 15:02
  • 11
    @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. – agweber Jan 08 '16 at 17:36
  • 5
    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. – Monty Harder Jan 08 '16 at 18:23
  • 2
    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. – derobert Jan 08 '16 at 21:32
  • 2
    @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. – Lie Ryan Jan 09 '16 at 13:37
  • @MontyHarder Having to press the power button on a multi-seat actually has a neat advantage: accountability (you immediately know who did it). In the end, it's always up to the administrator (root) to decide whether to allow local users to do it, depending on the local culture. – loopbackbee Jan 09 '16 at 15:19
  • @derobert That's certainly not true for all GUIs, but I see your point. I've added a mention to polkit in the answer, feel free to expand it (I'm not too familiar with it). – loopbackbee Jan 09 '16 at 15:29
  • Pedantic note: I don't believe the PDP-8 ran Unix. Try the PDP-11. – Oddthinking Jan 10 '16 at 04:29
  • @MontyHarder nit-picking here: You can get GUI over ssh. But usually you do not have the polkit-rights bcz of exactly the reason you wrotr – ljrk Jan 10 '16 at 11:47
47

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.

Fred
  • 505
  • Could you add to this answer to address the how/why the GUI had poweroff permissions? – user1717828 Jan 07 '16 at 22:01
  • 2
    Worth noting is that you could expand the "disrupted users" to those consuming the services running on the machine (databases, web services in particular). – jpmc26 Jan 07 '16 at 22:25
  • 3
    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. – rackandboneman Jan 08 '16 at 10:41
36

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.

Ijaz Ahmad
  • 7,202
  • 1
    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. – Warbo Jan 07 '16 at 15:06
  • It is mostly for servers , on which X11 forwarding is disabled for security reasons. – Ijaz Ahmad Jan 07 '16 at 15:09
  • 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. – Ijaz Ahmad Jan 07 '16 at 15:10
  • I was pointing out that "using a GUI" doesn't imply "physically present" (or more specifically "able to press the power button"), and hence there's not a simple distinction like "GUI = physically present, terminal = SSH". You covered this by saying it's a policy issue; I was highlighting how a bad policy could affect users in a thin client setup. BTW thin clients don't imply VMs; as others have said, Unix has always been a multi-user system. – Warbo Jan 07 '16 at 15:13
  • 1
    But by your policy you can make sure that GUI only means physically present. Disable X11 forwarding and disable ssh root login. – Ijaz Ahmad Jan 07 '16 at 15:16
  • Yes, it's a policy choice like you say. Of course, I could still tunnel a VNC session through a WebSocket (e.g. NoVNC, WebSockify and x11vnc) ;) – Warbo Jan 07 '16 at 15:19
  • If you guys had tried it with remote X11 you would find it's not allowed. The X11 path explicitly checks for local X session. – Joshua Jan 07 '16 at 21:36
  • 2
    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. – rackandboneman Jan 08 '16 at 10:43
10

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...

Toby Speight
  • 8,678
  • 1
    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? – supercat Jan 09 '16 at 19:35
7

For the 1st question:

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.

You can also figure-out:

$ 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.

Also visit related question: Why do we need to be root in terminal for shutdown and restart?

For the 2nd question:

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.

Also visit related question: How does the power button shut the computer down without root permission?

Community
  • 1
Pandya
  • 24,618
  • 27
    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". – David Richerby Jan 07 '16 at 11:39
  • @DavidRicherby Hmm.. OK. I revised post – Pandya Jan 08 '16 at 11:29
3

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

pseyfert
  • 868
  • So if I have execution rights on reboot, then what's stopping anyone from executing it? – Rohan Jan 12 '16 at 03:29