[SOLVED] elogind polkit rules?

GazL · 12-08-2020, 09:41 AM

Guys, are there any polkit-1 rules files to control what a user does with loginctl? Specifically, I'm looking to limit poweroff/reboot. It looks like any user can just shutdown or reboot regardless of whether they are in the 'power' group or not.

I don't install kde, so I might be missing some config files if they're somewhere in the kde set. I just run xdm and fvwm.

Am I missing some polkit rules because I didn't install the kde set, or are they just not implemented yet? If so, could someone please point me at the package.

Chuck56 · 12-08-2020, 10:22 AM

Quote:

Originally Posted by GazL

Guys, are there any polkit-1 rules files to control what a user does with loginctl? Specifically, I'm looking to limit poweroff/reboot. It looks like any user can just shutdown or reboot regardless of whether they are in the 'power' group or not.

I don't install kde, so I might be missing some config files if they're somewhere in the kde set. I just run xdm and fvwm.

Am I missing some polkit rules because I didn't install the kde set, or are they just not implemented yet? If so, could someone please point me at the package.

Is this what you're looking for?

ls -1 /etc/polkit-1/rules.d

Code:

10-enable-powerdevil-discrete-gpu.rules
10-enable-session-power.rules
10-enable-suspend.rules
10-enable-upower-suspend.rules
10-org.freedesktop.NetworkManager.rules
20-plugdev-group-mount-override.rules
30-blueman-netdev-allow-access.rules
50-default.rules

cat 10-enable-session-power.rules

Code:

polkit.addRule(
  function(action, subject) {
    if ( (action.id == "org.freedesktop.login1.reboot" ||
          action.id == "org.freedesktop.login1.reboot-multiple-sessions" ||
          action.id == "org.freedesktop.login1.power-off" ||
          action.id == "org.freedesktop.login1.power-off-multiple-sessions")
           && subject.isInGroup("power") ) {
      return polkit.Result.YES;
    }
  }
);

the rules can be found in /kde/powerdevil-5.20.4-x86_64-1.txz

Hope that helps!

GazL · 12-08-2020, 10:39 AM

thanks I'll check those out.

I tried rolling my own based on the NetworkManager example:

Code:

polkit.addRule(
  function(action, subject) {
    if ( action.id.indexOf("org.freedesktop.login1.power-off") ) {
       if ( subject.isInGroup("power") ) {
          return polkit.Result.YES;
       } else {
          return polkit.Result.NO;
       } 
    }
  }
);

... but that doesn't seem to work. I don't know javascript, so I was guessing at the syntax. I was using this as a guide:
https://www.freedesktop.org/software...op.login1.html

upnort · 12-08-2020, 11:05 AM

Hopefully this information lands in the future CHANGES AND HINTS?

_peter · 12-08-2020, 11:36 AM

definitely a good point, same wonder, same issue on polkit here. scary for servers.
it seems something got identified in elogin circa feb 2020 and changed in version 246? circa december 2020, i am lost here.

with a root user logged in on the machine the suspend command will not be honored unless -i is issued. but that doesn't address our issue.

Quote:

$ loginctl suspend
User root is logged in on tty1.
Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'loginctl suspend -i'.

GazL · 12-08-2020, 11:41 AM

Interestingly, if you >/dev/null then it doesn't need the "-i", which seems kind of buggy behaviour to me.

_peter · 12-08-2020, 11:47 AM

Quote:

Originally Posted by GazL

kind of buggy behaviour

agreed

you would say that polkit + elogind code should just work properly together and that's it, right ?
with time it will i suppose, it seems we are on elogind-243.7-x86_64-1 for now, maybe i will work with 246 and above

GazL · 12-08-2020, 01:28 PM

Ok, this seems to prevent it:

Code:

polkit.addRule(
  function(action, subject) {
     if ( action.id.indexOf("org.freedesktop.login1.power-off") == 0 ) {
          return polkit.Result.NO;
     }
     if ( action.id.indexOf("org.freedesktop.login1.reboot") == 0 ) {
          return polkit.Result.NO;
     }
  }
);

Just need to figure out the power group bit now...

GazL · 12-08-2020, 02:31 PM

Got there in the end, this was what I was aiming for:

Code:

/* /etc/polkit-1/rules.d/10-org.freedesktop.login1.rules: */

polkit.addRule(
  function(action, subject) {
     if ( action.id.indexOf("org.freedesktop.login1.power-off") == 0 ) {
        if ( action.id == "org.freedesktop.login1.power-off" ) {
            if ( subject.isInGroup("power") ) {
               return polkit.Result.YES;
            }
        }
        return polkit.Result.NO;
     }

     if ( action.id.indexOf("org.freedesktop.login1.reboot") == 0 ) {
        if ( action.id == "org.freedesktop.login1.reboot" ) {
            if ( subject.isInGroup("power") ) {
               return polkit.Result.YES;
            }
        }
        return polkit.Result.NO;
     }
  }
);

result: reboot and poweroff can be done by any user in group "power" so long as there are not multiple active sessions, or any other inhibitors: Users not in "power" can't shutdown or reboot at all. This feels like a good default to me.

I just need to think about what I'm going to do with the suspend/hibernate rules now.

I'll mark this as solved. Thanks to all who commented.

chrisVV · 12-09-2020, 04:03 AM

GazL, your workaround does the job but I am not convinced it should be necessary. The elogind package provides default rules in /usr/share/polkit-1/actions/org.freedesktop.login1.policy. These seem to allow amongst many other things a single user in an active session to power-off and reboot without additional authentication. Possibly elogind does not detect an active user correctly.

Edit: Something weird is going on for me after starting xfce using a DM, in my case lightdm. Entering as root 'loginctl list' gives "No sessions", and 'loginctl list-users' gives "No users". If I start from the console with startx, then I get the correct results.

Solved: I needed to add a line 'session optional pam_elogind.so' to my DM's pam file in /etc/pam.d.

GazL · 12-09-2020, 04:31 AM

The policy also allows an active user to shutdown multiple-sessions.

Code:

 <action id="org.freedesktop.login1.power-off-multiple-sessions">
                <description gettext-domain="systemd">Power off the system while other users are logged in</description>
                <message gettext-domain="systemd">Authentication is required for powering off the system while other users 
are logged in.</message>
                <defaults>
                        <allow_any>auth_admin_keep</allow_any>
                        <allow_inactive>auth_admin_keep</allow_inactive>
                        <allow_active>yes</allow_active>
                </defaults>
                <annotate key="org.freedesktop.policykit.imply">org.freedesktop.login1.power-off</annotate>
        </action>

I suppose it could also be tightened up by changing the policy to "no", or "auth_admin", which would lock it down a little more, but personally I prefer to tie the ability to shutdown/reboot to the 'power' group like it used to be, and for that rules are required (as far as I can tell).

Pat may not even want to change this. Maybe some folk prefer this level of permissiveness, but I'm more comfortable locking it down.

P.S.
I've only tried this with xdm and on the tty consoles. I don't use any other DMs.

Petri Kaukasoina · 12-09-2020, 04:55 AM

Quote:

Originally Posted by GazL

Maybe some folk prefer this level of permissiveness, but I'm more comfortable locking it down.

I've only tried this with xdm and on the tty consoles.

Can a random remote ssh user shut down the system? Or is it only for the console? (I'm totally ignorant of this systemd stuff so far.)

GazL · 12-09-2020, 05:26 AM

I only started looking at this stuff yesterday, so I'm learning as I go alone, but, as the ssh login is not in a login1 session I assume the <allow_any> rule in the policy applies, which says "auth_admin_keep": i.e. prompt the user for the admin password, but as there's no mechanism in ssh to provide that dialog it should fail.

Feels kind of messy though. Maybe <allow_any> should be "no" for these options?