Bug 1269726 - add a new EnforceInhibitors=(unprivileged|global) option to logind.conf to extend inhibitor lock enforcement to root
add a new EnforceInhibitors=(unprivileged|global) option to logind.conf to ex...
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
7.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: David Tardon
qe-baseos-daemons
Marie Dolezelova
: FutureFeature
Depends On:
Blocks: 1203710 1297395 1298243 1420851 1466365 1549617 1551061
  Show dependency treegraph
 
Reported: 2015-10-08 01:22 EDT by Ryan Sawhill
Modified: 2018-06-01 11:19 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ryan Sawhill 2015-10-08 01:22:45 EDT
Inhibitor locks are awesome. While one user is in the middle of something, we can prevent some non-root user with console access from rebooting, sleeping, shutting down. Awesome.

Unfortunately, the vast majority of server installations never have physical logins; it's most common that users only login over ssh. So:

 1) Users login over ssh
 2) Non-root users don't get magic power to reboot over ssh; therefore, non-root users understand that they always need root access to reboot
 3) So non-root users always use su/sudo to reboot the machine, making inhibitor locks useless

See where I'm going with this? What if we could also warn root users that try to, e.g., reboot when block-locks are present? Use case:

 1) Multiple users have sudo access
 2) One user uses sudo systemd-inhibit to start some important process that should not be interrupted ... or maybe they're simply doing package-management operations
 3) Another user comes in, runs into an issue and decides to sudo reboot but instead of rebooting, thankfully, the command errors out with a warning and explanation (with hint that systemctl reboot --ignore-inhibitors could be used)

Of course you can use /run/nologin to prevent new logins, but that doesn't help if someone has already su'd over to root. It just doesn't cover enough cases. This is a valid new feature that would be welcomed by many sysadmins.

See upstream RFE, including posititve comment from LP:

  https://github.com/systemd/systemd/issues/949

See this comment from LP in a related pull request:

  https://github.com/systemd/systemd/pull/950#issuecomment-131552803

There, he says:

> I would prefer if this would be an option only, not a change of defaults.
> And then it should be enforced by logind, and systemctl would have to
> query the setting from logind and show the inhibitor list depending on
> what it exposes.
> 
> Or in other words, I think the patch needs to be more complex:
> 
> 1. logind.conf should gain a new setting EnforceInhibitors= which should
> take an enum, with currently two possible values: "unprivileged" (which
> would be the default and identical to the old behaviour), "global" (which
> would be the new added option, and extend inhibitor enforcement to root).
> 
> 2. this setting should be taken into account for all relevant polkit
> checks by logind
> 
> 3. logind should expose this setting as bus property on its Manager
> object
> 
> 4. systemctl should read the prop before showing the inhibitor list, and
> show it even for root if the setting is "global".
> 
> 5. the man pages need to be updated to document the new setting.
Comment 5 Lukáš Nykrýn 2017-11-07 08:05:32 EST
This still needs to be implemented in upstream. NOthing we can make to rhel-7.5

Note You need to log in before you can comment on or make changes to this bug.