Bug 1269726

Summary:	extend inhibitor lock enforcement to root
Product:	Red Hat Enterprise Linux 8	Reporter:	Ryan Sawhill <rsawhill>
Component:	systemd	Assignee:	Jacek Migacz <jmigacz>
Status:	CLOSED ERRATA	QA Contact:	Frantisek Sumsal <fsumsal>
Severity:	medium	Docs Contact:	Prerana Sharma <presharm>
Priority:	medium
Version:	8.0	CC:	apmukher, bugzilla, dchong, dshaw, dtardon, fhirtz, fsumsal, jbreitwe, jmigacz, joedward, ktordeur, kwalker, lnykryn, mark, mschorm, mschorm, msekleta, pdwyer, rsawhill, systemd-maint-list, todoleza
Target Milestone:	rc	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	systemd-239-50.el8	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:
Clones:	2021309 (view as bug list)		Environment:
Last Closed:	2021-11-09 19:54:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1203710, 1297395, 1298243, 1420851, 1466365, 1549617, 1551061, 1643104, 2021309

Description Ryan Sawhill 2015-10-08 05:22:45 UTC

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 13:05:32 UTC

This still needs to be implemented in upstream. NOthing we can make to rhel-7.5

Comment 7 David Tardon 2018-06-21 13:57:00 UTC

for the record: a patch is on review upstream: https://github.com/systemd/systemd/pull/9356

Comment 8 Michal Sekletar 2018-07-18 12:54:09 UTC

(In reply to David Tardon from comment #7)
> for the record: a patch is on review upstream:
> https://github.com/systemd/systemd/pull/9356

Seems like this is stalled upstream. Moving to rhel-7.7.

Comment 11 Michal Schorm 2018-12-02 04:56:04 UTC

(In reply to Ryan Sawhill from comment #0)

Hello Ryan, I stumbled upon the same problem on my Fedora 29 server.

Would you be willing to share your current workaround for this issue, so I woldn't re-invent the wheel?

--

Currently:
* The root will ignore the inhibitor locks.
* Regular user can't use `wall`:
  [regular-user@SERVER ~]$ systemctl suspend -i
  ==== AUTHENTICATING FOR org.freedesktop.login1.set-wall-message ====
  Authentication is required to set a wall message
  Authenticating as: root
  Password: 
* While the Debian / Ubuntu has "/usr/bin/wall" set with gid bit for group "tty", so you can just add the user there, on Fedora it is "-rwxr-xr-x. root root", so you can't do that.
* And even it the previous point was changed manually and it wouldn't break anything else, I heard somewhere, that systemd has its own implementation of `wall`, so it won't help anyway.
* One can update sudoers (as suggested on ArchLinux wiki), allowing regular user to use "/usr/bin/systemctl suspend". However the command will be ran under root anyway, ignoring inhibitor locks again.
* Polkit can't be used on headless server which does not have it at all. (As suggested on some Ubuntu forum)


I also probabbly didn't understood what are inhibitors locks good for in the current implementation, beacuse regular users can't invoke commands which works with them (shutdown, reboot, suspend, ...) and root user ignores them.

Comment 12 Ryan Sawhill 2018-12-03 03:27:10 UTC

(In reply to Michal Schorm from comment #11)
> Hello Ryan, I stumbled upon the same problem on my Fedora 29 server.
> 
> Would you be willing to share your current workaround for this issue, so I
> woldn't re-invent the wheel?

Many moons ago, I wrote reboot-guard (https://github.com/ryran/reboot-guard) for a customer (and myself), in lieu of this fix.

Warning: while I'm a redhatter, reboot-guard is not a Red Hat product and should of course be considered as 3rd-party unsupported software. Any questions/feedback should go to the issue-tracker on github.

Comment 13 Michal Schorm 2019-06-11 20:29:35 UTC

Is there any upstream (Fedora? or Systemd?) tracker for this issue / feature request?
If it doesn't exist, can you create it?
Can you link it to this BZ?

What's the overall status on the upstream side?

Comment 14 David Tardon 2020-03-31 12:37:20 UTC

(In reply to Michal Schorm from comment #13)
> Is there any upstream (Fedora? or Systemd?) tracker for this issue / feature
> request?

Yes, there is.

> What's the overall status on the upstream side?

I implemented the config. option proposed here, but the patch was rejected. Nothing has changed since then.

Comment 15 David Tardon 2020-03-31 12:44:50 UTC

Also, moving this to RHEL-8 as there won't be any further feature backports for RHEL-7.

Comment 23 Lukáš Nykrýn 2021-07-23 14:21:22 UTC

fix merged to github master branch -> https://github.com/redhat-plumbers/systemd-rhel8/pull/194

Comment 37 errata-xmlrpc 2021-11-09 19:54:49 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (systemd bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4469