RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1269726 - extend inhibitor lock enforcement to root
Summary: extend inhibitor lock enforcement to root
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemd
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jacek Migacz
QA Contact: Frantisek Sumsal
Prerana Sharma
URL:
Whiteboard:
Depends On:
Blocks: 1203710 1297395 1298243 1420851 1466365 1549617 1551061 1643104 2021309
TreeView+ depends on / blocked
 
Reported: 2015-10-08 05:22 UTC by Ryan Sawhill
Modified: 2021-11-10 09:46 UTC (History)
21 users (show)

Fixed In Version: systemd-239-50.el8
Doc Type: Enhancement
Doc Text:
Clone Of:
: 2021309 (view as bug list)
Environment:
Last Closed: 2021-11-09 19:54:49 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github redhat-plumbers systemd-rhel8 pull 194 0 None open (#1269726) extend inhibitor lock enforcement to root 2021-07-05 13:53:43 UTC
Github systemd systemd pull 18210 0 None closed Added option --check-inhibitors for non-tty usage 2021-02-15 14:43:02 UTC
Github systemd systemd pull 18316 0 None closed logind: Introduce RebootWithFlags and others 2021-02-15 14:43:03 UTC
Github systemd systemd pull 18933 0 None open logind: add …WithFlags methods to policy 2021-03-09 08:59:11 UTC
Red Hat Product Errata RHBA-2021:4469 0 None None None 2021-11-09 19:55:24 UTC

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
Note You need to log in before you can comment on or make changes to this bug.