Why does hostnamectl not require a password to change the hostname?

Question

It seems that the new way to change the hostname with systemd is:

hostnamectl set-hostname NEWNAME

However, this does not require a password when logged in as a user with admin rights (not sure which group counts). In the case of non-admin users, it pops up a dialog requesting the password for one of the privileged users.

I think "shutdown -h now" even works for non-admin users.

I assume these are both new systemd-related commands.

How do they check if the user submitting the commands has the rights to run them? How can I make them ask for a password or require sudo?

Answer 1

In systemd and related utilities, the actions that might require privileged access are routed through PolicyKit. Run pkaction without any parameters to see the list of all the possible actions handled by PolicyKit. To see the current policy for a specific action, use pkaction --verbose --action-id <action identifier. For example, changing the hostname:

# pkaction | grep host
org.freedesktop.hostname1.set-hostname
org.freedesktop.hostname1.set-machine-info
org.freedesktop.hostname1.set-static-hostname

# pkaction --verbose --action-id org.freedesktop.hostname1.set-hostname
org.freedesktop.hostname1.set-hostname:
  description:       Set host name
  message:           Authentication is required to set the local host name.
  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:   auth_admin_keep

So the current policy on my system for hostname changes is auth_admin_keep - that is, require a password of an administrator unless the user has very recently successfully passed a similar check (just like sudo it can avoid consecutive password requests).

And who is an administrator whose password can authorize these actions? On my Debian 9 system, this is determined by files in /etc/polkit-1/localauthority.conf.d/ directory - by default, only root and members of the sudo user group will qualify.

If you don't like this policy, you can easily change it by writing some custom PolicyKit configuration files.

PolicyKit can be configured to require any the following "security levels" for any action managed by it:

• yes - user can always do it, no questions asked
• auth_self_keep - if the user hasn't recently done anything requiring a password check, request user's password to ensure it's really him/her. If multiple consecutive actions of this level are executed within a few-minute window, the checks can be skipped after the first one.
• auth_self - always require user's password check
• auth_admin_keep - require the password of an administrative user. Just like auth_self_keep, after the password (and optionally the admin username) is entered once, the user can execute multiple actions of this level within a brief time window without further password requests
• auth_admin- always require a password check, and the user responding to the password check must be one of the administrative users
• no - the action is rejected without any further questions.

The time the ..._keep results are maintained is apparently hard-coded in PolicyKit upstream code: here's a link to PolicyKit Git.

/* TODO: right now the time the temporary authorization is kept is hard-coded - we
 *       could make it a propery on the PolkitBackendInteractiveAuthority class (so
 *       the local authority could read it from a config file) or a vfunc
 *       (so the local authority could read it from an annotation on the action).
 */
 expiration_seconds = 5 * 60;

There does not currently seem to be any provisions for configuring this value at run-time, nor for extending the authentication time-stamp once it's set.

OpenSuSE seems to have extended this with ...keep_session and ...keep_always results. Apparently they've also reinterpreted the ...keep actions to mean "remember the result for as long as the asking process keeps running."