What are the default Polkit privileges on Arch Linux for shutdown, halt, etc., and why are they so?

Question

On Arch Linux, with systemd, the following commands are all symlinks to systemctl:

/usr/bin/telinit
/usr/bin/poweroff
/usr/bin/runlevel
/usr/bin/reboot
/usr/bin/halt
/usr/bin/shutdown

I find their behaviour with respect to authorization confusing:

$ shutdown
Must be root.
$ halt
Must be root.
$ telinit 3
# Asks for Polkit authorization

Neither poweroff nor reboot asks for authorization. poweroff doesn't actually turn off my system, the laptop remains on with text on the screen stating it is powering off - indefinitely.

I haven't tinkered with Polkit rules, so I wonder why their behaviour is so.

• All commands were tried with my non-root admin user, who's a member of wheel.

• /etc/polkit-1/rules.d only seems to contain a default ruleset:

  # tail /etc/polkit-1/rules.d/*
  // DO NOT EDIT THIS FILE, it will be overwritten on update
  //
  // Default rules for polkit
  //
  // See the polkit(8) man page for more information
  // about configuring polkit.
  
  polkit.addAdminRule(function(action, subject) {
      return ["unix-group:wheel"];
  });
  

On closer inspection, /usr/share/polkit-1/actions/org.freedesktop.login1.policy has sections for poweroff, reboot, suspend and hibernate, with allow_active set to yes. But there are no sections for shutdown. If this is the cause, why is it so?

Answer 1

This is pretty complicated. Let's explain the commands in order you've enumerated them.

1. telinit

   Various arguments to telinit directly translate to various (different) subcommands of systemctl. As per telinit(8) (documentation from systemd package):

   2, 3, 4, 5

   Change the SysV runlevel. This is translated into an activation request for runlevel2.target, runlevel3.target, ... and is equivalent to systemctl isolate runlevel2.target, systemctl isolate runlevel3.target, ...

   So, these commands translate to systemctl isolate, which itself is governed by polkit action org.freedesktop.systemd1.manage-units. Privileges for that action default to requiring admin authentication — both for active sessions, inactive sessions and processes outside of any session.

   (BTW, by default polkit is configured such that it treats any user in wheel group as an admin. Thus you were prompted to authenticate for yourself.)

2. halt, poweroff, reboot

   Commands poweroff and reboot work in two steps:

   • if invoked under a non-root-user and logind is available, logind is asked to perform the action, using polkit actions org.freedesktop.login1.*;
   • otherwise, the almost-equivalent of systemctl poweroff or systemctl reboot is executed, but without consulting polkit.

   halt is similar, but it always goes the second route (almost-equivalent of systemctl halt). There is no method for halting via logind.

   Note the "almost-equivalent". In case you do

   • poweroff under a non-root without logind,
   • reboot under a non-root without logind,
   • halt under a non-root,

   you get a "Must be root." instead of authenticating for org.freedesktop.systemd1.manage-units via polkit. At the same time, with systemctl poweroff, systemctl reboot or systemctl halt you will be given a chance to authenticate via polkit. This is probably a bug.

3. shutdown

   This tool can be used to schedule a delayed poweroff, halt or reboot. If invoked without arguments, a delay of 1 minute is implied. The default action is power-off. From shutdown(8):

   The time string may either be in the format "hh:mm" for hour/minutes specifying the time to execute the shutdown at, specified in 24h clock format. Alternatively it may be in the syntax "+m" referring to the specified number of minutes m from now. "now" is an alias for "+0", i.e. for triggering an immediate shutdown. If no time argument is specified, "+1" is implied.

   If timeout and wall message are not specified, shutdown is equivalent to one of poweroff, halt or reboot (see #2).

   If either a timeout or a wall message is specified, shutdown requires root privileges.

4. poweroff doesn't power off

   It really should. This is probably a kernel bug.