Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
(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.
(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.
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?
(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.
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