Overriding polkit actions

Cvlc · 2024-06-27 10:21:31

The wiki states that

The defaults can be overruled but editing the actions files is NOT the correct way.

However it doesn't seem to mention what is the correct way, similarly to /etc/polkit-1/rules.d/

I'd like to modify the following snippet to use auth_admin_keep for inactive sessions. Despite (mostly valid) run0 criticism, I guess this would let me use it with an auth timeout like sudo.

# cat /usr/share/polkit-1/actions/org.freedesktop.login1.policy
...
        <action id="org.freedesktop.systemd1.manage-units">
                <description gettext-domain="systemd">Manage system services or other units</description>
                <message gettext-domain="systemd">Authentication is required to manage system services or other units.</message>
                <defaults>
                        <allow_any>auth_admin</allow_any>
                        <allow_inactive>auth_admin</allow_inactive>
                        <allow_active>auth_admin_keep</allow_active>
                </defaults>
        </action>
...

By the way, the polkit manpage mentions

Like auth_admin but the authorization is kept for a brief period (e.g. five minutes).

Does Arch set this anywhere ?

Thanks !

Lone_Wolf · 2024-06-27 10:54:48

Create a rule file in /etc/polkit-1/rules.d to override defaults .
see https://wiki.archlinux.org/title/Polkit … tion_rules

Cvlc · 2024-06-27 11:40:46

Alright, I had this all backwards. Thanks. However, while I can get "Result.YES" to work, using "ADMIN_KEEP" as below prompts me for my password everytime:

polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.systemd1.manage-units") &&
        subject.isInGroup("wheel")) {
            return polkit.Result.AUTH_ADMIN_KEEP;
    }
});

Last edited by Cvlc (2024-06-27 11:44:43)

seth · 2024-06-27 13:35:29

What does "everytime" mean? The cache expires after 5 minutes, https://unix.stackexchange.com/question … ng-a-pkexe (don't bother, it's hardcoded)

Cvlc · 2024-06-27 14:33:45

literally every time, even after just a few seconds

5 min is alright, but funny that they should hard code it.

seth · 2024-06-27 15:20:50

https://unix.stackexchange.com/question … horization
Is the problem limited to systemdumb?

Cvlc · 2024-06-27 16:41:29

I don't think so, it looks like FirewallD is set to AUTH_KEEP by default, but it still requires the password upon every lauch

  <action id="org.fedoraproject.FirewallD1.all">
    <description>Firewall</description>
    <message>System policy prevents inspecting and changing firewall</message>
    <defaults>
      <allow_any>auth_admin_keep</allow_any>
      <allow_inactive>auth_admin_keep</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.imply">org.fedoraproject.FirewallD1.info org.fedoraproject.FirewallD1.config org.fedoraproject.FirewallD1.config.info org.fedoraproject.FirewallD1.direct org.fedoraproject.FirewallD1.direct.info org.fedoraproject.FirewallD1.policies org.fedoraproject.FirewallD1.policies.info</annotate>
  </action>

seth · 2024-06-27 22:15:00

Do you get asked in the shell or by some polkit agent? (GUI dialog)

Cvlc · 2024-06-28 05:52:47

I get asked by the polkit agent, which is expected

seth · 2024-06-28 05:55:12

Which one?
If you set /usr/share/polkit-1/actions/org.freedesktop.policykit.policy to admin_auth_keep, does it remember the authentication for pkexec ?

ua4000 · 2024-06-30 10:33:57

I made the same observations, a rule with YES works, but AUTH_ADMIN_KEEP or AUTH_SELF_KEEP are not honored.
Tested with pkttyagent and lxqt-policykit-agent.

The above link from seth is 2 years old and also not solved, maybe it's a bug ?

At https://gist.github.com/grawity/3886114 I found this comment:

Note that AUTH_ADMIN_KEEP is kept per process, hence if another process ID is asking for the same action this will lead to a reauthentication.

And in addition I found this in the polkit manpage, which questions the security of polkit at whole for me when using the KEEP:

Keep in mind that if polkit.Result.AUTH_SELF_KEEP or polkit.Result.AUTH_ADMIN_KEEP is returned, authorization checks for the same action identifier and subject will succeed (that is, return polkit.Result.YES) for the next brief period (e.g. five minutes) even if the variables passed along with the check are different. Therefore, if the result of an authorization rule depend on such variables, it should not use the "*_KEEP" constants (if similar functionality is required, the authorization rule can easily implement temporary authorizations using the Date[9] type for timestamps).

Last edited by ua4000 (2024-06-30 10:34:48)

seth · 2024-06-30 14:54:17

But you're using the same binary/action?

If I change /usr/share/polkit-1/actions/org.freedesktop.policykit.policy to auth_admin_keep, setup a pkttyagent to listen to the interactive shell I'm gonna use for testing (I don't have any other agents running and pkexec is stupid - if you're running an agent that should™ not be becessary) and "pkexec ls", it'll ask me for creds once, but not subsequently (if I repeat fast enough)
Can you confirm this?

ua4000 · 2024-07-01 16:18:49

I have for testing this rule for date command installed:

// sudoedit /etc/polkit-1/rules.d/40-wheel.rules
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.policykit.exec" &&
        action.lookup("program") == "/usr/bin/date") {
        return polkit.Result.AUTH_ADMIN_KEEP;
    }
});

pkexec :

$ echo $$
9307
$ pkexec /usr/bin/date
			==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
			Authentication is needed to run `/usr/bin/date' as the super user
			Authenticating as: me
			Password: 
			==== AUTHENTICATION COMPLETE ====
2024-07-01T18:01:35 CEST
$ pkexec /usr/bin/date
2024-07-01T18:01:48 CEST
$ pkexec /usr/bin/date
2024-07-01T18:01:51 CEST

The agent is running in a 2nd terminal ( $ pkttyagent --process 9307), I inserted the agent in+out above manually right aligned.
(There seems an open bug, that pkttyagent ist not called by pkexec automatically.)
--> Result: pkttyagent is invoked only once for user auth.

run0 :

$ run0   /usr/bin/date
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: me
Password: 
==== AUTHENTICATION COMPLETE ====
2024-07-01T18:02:03 CEST
$ run0   /usr/bin/date
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: me
Password: 
==== AUTHENTICATION COMPLETE ====
2024-07-01T18:02:10 CEST
$ run0   /usr/bin/date
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to manage system services or other units.
Authenticating as: me
Password: 
==== AUTHENTICATION COMPLETE ====
2024-07-01T18:02:14 CEST

--> Result: pkttyagent is invoked every time for user auth.

seth · 2024-07-01 16:24:31

Is this w/ https://bbs.archlinux.org/viewtopic.php … 9#p2180629 still in place?
Does it alone allow to remember the creds for pkexec?

ua4000 · 2024-07-01 16:37:15

The rule from the other post I have removed for this last test.
What should I test now ? Sorry, I do not quite understand.

seth · 2024-07-01 16:39:43

action.id == "org.freedesktop.policykit.exec" will probably not help you w/ run0 and I can't find what action it employs (because googling that only gets you puff pieces about lennarts new super safe sudo replacement and people arguing whether it uses polkit… )
However the general rule from your other thread should™ either affect both or none.

Edit: likewise should the policy menitoned in #12

Last edited by seth (2024-07-01 16:40:18)

ua4000 · 2024-07-01 17:17:46

// sudoedit /etc/polkit-1/rules.d/40-wheel.rules
polkit.addRule(function(action, subject) {
	if ( subject.isInGroup("wheel") ) { 
		return polkit.Result.AUTH_ADMIN_KEEP; 
		//return polkit.Result.AUTH_SELF_KEEP; 
		//return polkit.Result.YES; 
	}
});

pkexec /usr/bin/date
--> 3x called: 3 times pkttyagent asks

run0 /usr/bin/date
--> 3x called: 3 times pkttyagent asks

AUTH_ADMIN_KEEP --> YES changed:
strange (this does not match my observation on the other closed post): no effect this time I also restartet polkitd. Same result as above: 6x pkttyagent asks

3rd test, removing the above rule, changing the actions file:

// sudoedit  /usr/share/polkit-1/actions/org.freedesktop.policykit.policy
//      <allow_any>auth_admin</allow_any>
//      <allow_inactive>auth_admin</allow_inactive>
//      <allow_active>auth_admin</allow_active>
      <allow_any>auth_admin_keep</allow_any>
      <allow_inactive>auth_admin_keep</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>

pkexec /usr/bin/date
--> 3x called: 1 times pkttyagent asks --> OK

run0 /usr/bin/date
--> 3x called: 3 times pkttyagent asks

Last edited by ua4000 (2024-07-01 17:18:40)

seth · 2024-07-01 21:32:03

For a cross-check, does run0 respond to a "yes" instead of "auth_admin" there?

ua4000 · 2024-07-02 15:37:14

no, with

      <allow_any>yes</allow_any>
      <allow_inactive>yes</allow_inactive>
      <allow_active>yes</allow_active>

it's the same:

run0 /usr/bin/date
--> 3x called: 3 times pkttyagent asks

I have the impression, run0 as oneshot replacement for sudo work and is very safe, but further config like KEEP or no password for special commands e.g. smartctl is not fully thought through.
Or not good published/documented so far.

One can come to the idea, /usr/bin/run0 has to be put into an polkit action with AUTH_ADMIN_KEEP ... :-) But that's nonsense right ?

Last edited by ua4000 (2024-07-02 15:37:43)

seth · 2024-07-02 15:49:19

Why do you think run0 is "very safe" or safer than sudo?

Because lennart said that? He also said it's easier to confingure than the convoluted sudo config - go figure…
You'd need a documentation for it's polkit actions, yes.
Of course if you just can't configure anything and everyone who can enter their password can run0 anything, that's much easier from a config POV.
Not sure about the safety part, though…

ua4000 · 2024-07-02 15:57:36

I read in the manpage these keyword in the preamble, and it "sounds" better than sudo:

isolating the authentication prompt
independent pseudo-tty
detaching its lifecycle and isolating

seth · 2024-07-02 16:15:00

The preamble also says "No SetUID/SetGID file access bit functionality is used for the implementation." which not true (and bullshit on the entire suid-is-bad axiom) but lennart will tell you otherwise because polkit uses the suid, not run0.
Which is like me saying "I didn't fuck your daughter, my penis did"

run0 is a wrapper around systemd-run that uses polkit for privilege escalation and the three listed items are merely an implicit result of that.
It inherits the features of systemd-run - which can be good or really really bad, depending on the context (as is generally disowning stuff)
Some claimed advantages like about the clean environment are flat-out lies, sudo and doas don't preserve the environment by default either and you could also "sudo env -i …" or "sudo systemd-run …" if you really wanted.

Also somebody please has to explain to me how "thus isolating the authentication prompt from the terminal (if possible)" is "good" by any definition.
Faking a UAC client is a solid way to fuck windows users, training users to enter their password into something that looks like the polkit dialog is the same idiocy. Having the credential request in direct response to the intended action seems rather useful to me.

You can use run0 or not but all the marketing BS is marketing BS.
It's just yet another sudo and provides no inherent absolute benefits.

Cvlc · 2024-07-04 08:12:49

seth wrote:

Which one?
If you set /usr/share/polkit-1/actions/org.freedesktop.policykit.policy to admin_auth_keep, does it remember the authentication for pkexec ?

I am using the default one from Gnome.

Yes, if I set the above to admin_auth_keep, then pkexec remembers the authentication.

I agree with the run0 marketing, but I'd still like to understand why polkit doensn't behave as I would expect

seth · 2024-07-05 20:37:35

I'd still like to understand … polkit

I'm not sure how this is supposed to work at all - sudoers allows fine-grained control over how gets to run exactly what based on which credentials.
A polkit rule for just run0 (whatever action that's gonna be) doesn't achieve anything like this and it also seems completely undocumented besides "iT UsEs pOlKiT"

Fwwi, my terminal switches to red text all the time when I open a root shell since, like ever. That's really no great trick, /root/.zshrc

if [ -z $ORIGINAL_FG ]; then
    stty -echo
    stty raw >/dev/tty
    printf '\033]10;?\007' >/dev/tty
    ORIGINAL_FG="$(dd </dev/tty count=1 2>/dev/null)"
    stty cooked >/dev/tty
    ORIGINAL_FG="$(echo "$ORIGINAL_FG" | sed 's/[^[:print:]]//g')"
    stty echo
fi
printf '\033]10;#d02317\007'
TRAPEXIT() { # TRAPEXIT is a zsh thing, you'll need to trap yourself on bash… I think
    printf '\033'"$ORIGINAL_FG"'\007'
}

In case that's the selling point…

Cvlc · 2024-07-15 07:07:05

Hi, sorry for delayed answers I'm away for days in a row.

The only "selling point" would be why bother configuring sudoers if run0 is enough for someone's use case. But right now I'm really not trying to sell or buy anything, just making use of the occasion to try understand a little bit of polkit I might very well keep on using sudo, but I still want this to work because it should.

If you set /usr/share/polkit-1/actions/org.freedesktop.policykit.policy to admin_auth_keep, does it remember the authentication for pkexec ?

What was the reasoning behind this check ? thanks again for your time, have a good day !

Arch Linux

#1 2024-06-27 10:21:31

Overriding polkit actions

#2 2024-06-27 10:54:48

Re: Overriding polkit actions

#3 2024-06-27 11:40:46

Re: Overriding polkit actions

#4 2024-06-27 13:35:29

Re: Overriding polkit actions

#5 2024-06-27 14:33:45

Re: Overriding polkit actions

#6 2024-06-27 15:20:50

Re: Overriding polkit actions

#7 2024-06-27 16:41:29

Re: Overriding polkit actions

#8 2024-06-27 22:15:00

Re: Overriding polkit actions

#9 2024-06-28 05:52:47

Re: Overriding polkit actions

#10 2024-06-28 05:55:12

Re: Overriding polkit actions

#11 2024-06-30 10:33:57

Re: Overriding polkit actions

#12 2024-06-30 14:54:17

Re: Overriding polkit actions

#13 2024-07-01 16:18:49

Re: Overriding polkit actions

#14 2024-07-01 16:24:31

Re: Overriding polkit actions

#15 2024-07-01 16:37:15

Re: Overriding polkit actions

#16 2024-07-01 16:39:43

Re: Overriding polkit actions

#17 2024-07-01 17:17:46

Re: Overriding polkit actions

#18 2024-07-01 21:32:03

Re: Overriding polkit actions

#19 2024-07-02 15:37:14

Re: Overriding polkit actions

#20 2024-07-02 15:49:19

Re: Overriding polkit actions

#21 2024-07-02 15:57:36

Re: Overriding polkit actions

#22 2024-07-02 16:15:00

Re: Overriding polkit actions

#23 2024-07-04 08:12:49

Re: Overriding polkit actions

#24 2024-07-05 20:37:35

Re: Overriding polkit actions

#25 2024-07-15 07:07:05

Re: Overriding polkit actions

Board footer