Some Elogind actions bypass Polkit rules #149
seems to be ok, and they work properly with polkit rules. Commands like:
completely ignore the polkit rules.
I'm not sure if it's Elogind issue but I think it may be (other applications, like gparted, works correctly with polkit on my machine, after all). I did some tests on different distros and here we go:
The text was updated successfully, but these errors were encountered:
Some do indeed.
Example: If you are a regular user and the only user logged into your machine, pressing the suspend key on your laptop does not trigger a question for your password. If an inhibitor, like root being logged in on any tty, is present, you simply can't suspend.
Example: I have logged in as root on tty2
When I try the mentioned "-i" option, the system suspends nevertheless without asking for a password. This way lid-close-events can be used to suspend the system and won't leave your laptop running (and heating) in your backpack just because you forgot to log out root somewhere.
Same is with poweroff. You are the ruler of your system and must be able to power off your system.
Does MacOS ask you for your password when hitting "poweroff"?
Those three commands are meant to work when issued by a regular user.
btw: Neither the
So much for the basics and defaults.
In the gentoo forum post you wrote that you explicitly wrote polkit rules so that your particular user has to be asked for a password.
Well, this ought to work for reboot and poweroff, but elogind explicitly does not check extra rules for suspending and hibernating. This really is a difference to systemd, and that is so since June 2018.
The reason we removed any extra check but against inhibitors was the questioning of a password when hitting the suspend key on a laptop or closing its lid. It just didn't make any sense.
As far as I can see, the default rules haven't changed. So any user wanting to instantly suspending their system would have to learn to write custom polkit rules.
A possible solution might be to re-add the questioning of the rules while changing the defaults. Without changing the defaults, we'd end up breaking many user setups.
However, I can see why someone would not want any regular user to be able to suspend a multi-user system in an office or something like that.
...maybe it's about time to thinks again?
Personally I think it should be possible for polkit rules author to change the behavior when a user wants to suspend the system.
But how so? Change the defaults so it becomes a (working) opt-in, or leave the defaults like systemd so it becomes a then needed opt-out?
I personally I don't have a problem with the current behaviour since I only have single user systems and I don't think many people would want to restrict this, so making it working by default but making it possible to restrict access via polkit seems like the best way to go about this (it certainly is better to allow users to hibernate the system by default than my laptop going into nuclear fusion mode in my backpack :P)
Thank you very much guys for looking into it:) Yeah, nuclear fusion in a backpack is certainly not a good thing:)
As you can see it's not a problem for me (nor it should be for anyone familiar with Polkit) to write a rule that override the defaults. I only need a mechanism to work properly. Because, in current state, even if I change values directly in /usr/share/polkit-1/actions/org.freedesktop.login1.policy (not a good practice to change that file, it's better to write a .rules file instead) to ask everyone for a password when doing 'loginctl suspend' - it is ignored too.
To get crystal clear - I know the many people mind about Polkit. And I agree in regards to personal computer with single user - you are the administrator of your own PC. I also think that Polkit is mostly useless on a server (even in large corporate environment like mine) and that is one of the reasons why I'm trying to avoid RedHat and SUSE on my servers - Polkit is installed there by default and deleting it is not a trivial task. Sudo is sufficient on my servers. But virtual workstations is totally different thing - the admins for thousands of such workstations would be myself and my associate. We do not want users to be able to poweroff/reboot/suspend/hibernate those machines, it would make our job more difficult;) Yet, we still want to use Polkit to grant/deny certain users certain access to some GUI apps.
Wow, another wall of text from me;) I hope I wrote it in easy to understand way (English is not my native language). If I can be of any help in making Elogind fully compatible with Polkit I am more than eager to help:)
Thank you @Yamakuzure for highlighting that issue with that pretty colorful labels:) I just wonder if there are a lot of things to change in the source code to make it work. I'm just a weakling in coding myself but maybe you could point me in right direction? Am I right that there is something to change (uncomment maybe) in /src/login/logind-dbus.c ? Would it be sufficient? Sorry for asking, I just really care about it to make all the org.freedesktop.login1.* actions work properly with polkit (like logind in systemd) :) If that matter is more complicated then I will patiently wait for any news:)
@Acatorn No, there isn't much to change, but to test.
When suspending a machine using elogind, the checking off the credentials was removed to circumvent asking (privileged) users for their password when hitting the sleep key on their laptops or when closing the lid. This has the unfortunate side effect to also circumvent any custom policykit rules an administrator might add to their system to limit the circle of users being allowed to put the machine to sleep. Since the check was masked, the mechanics of credential checking has evolved, and it is no longer neccessary to mask the credential check. Whatever lead to elogind asking for authorization on machine suspension is fixed in all tests. Bug: #149 Closes: #149 Signed-off-by: Sven Eden <firstname.lastname@example.org> Cherry-picked-from: b187de7
I have removed the extra check. In my tests it looks like the masking is no longer needed.
Whatever lead to elogind asking for extra credentials on every attempt to suspend my laptop, must have been something that was fixed in the meantime. Even with re-enabled check I could suspend my machine without any changes to the default policykit rules.
@Acatorn: Your custom rules should work with the mentioned commit, which I also cherry-picked into v243-stable branch.
Generally speaking, polkit is optional. If it is not installed, the privilege checking done by elogind is limited to UID and capability checks. But users on single-user systems without polkit should be perfectly capable to suspend/hibernate their machine without the need to use sudo or similar, as this would make triggering suspension on critical battery levels, or when closing the lid of a laptop, almost useless. Before commit b187de7 elogind did not check on suspend/hibernate actions, because an issue with the policies made elogind asking for super-user credentials, which was basically the same issue. Bug: #149 Closes: #167 Signed-off-by: Sven Eden <email@example.com>
Generally speaking, polkit is optional. If it is not installed, the privilege checking done by elogind is limited to UID and capability checks. But users on single-user systems without polkit should be perfectly capable to suspend/hibernate their machine without the need to use sudo or similar, as this would make triggering suspension on critical battery levels, or when closing the lid of a laptop, almost useless. Before commit b187de7 elogind did not check on suspend/hibernate actions, because an issue with the policies made elogind asking for super-user credentials, which was basically the same issue. Bug: #149 Closes: #167 Signed-off-by: Sven Eden <firstname.lastname@example.org> (cherry picked from commit 38b4d54)