[SOLVED] Kde polkit permission issue

variable-root · 2022-06-04 01:19:27

Hello,
I am trying to change my system clock as it incorrect. I am using the KDE gui and clicking edit date/time. After altering the date/time clicking apply prompts for password which is rejected ("Authentication error. Please try again") despite being input correctly. Clicking the details buttons indicates the polkit.subject-pid, the polkit.caller-pid, and the ID: org.freedesktop.timedate1.set-ntp.

relevant log (with hostname and username redacted for security):
http://0x0.st/oM-r.txt

Any help is appreciated.

Last edited by variable-root (2022-06-04 23:00:12)

seth · 2022-06-04 06:04:52

org.freedesktop.timedate1.set-time is auth_admin_keep - is your user member of the "wheel" group?

variable-root · 2022-06-04 15:58:41

Yes the user is a member of the wheel group

cat /etc/group | grep 'wheel'
wheel:x:998:USERNAME_REDACTED

seth · 2022-06-04 16:23:49

Inside the running shell? (try "groups" if you just added yourself; usermod doesn't impact running shells itr.)

If that's not the problem, can you run "pkexec ls"?

variable-root · 2022-06-04 17:48:27

It was inside the running shell, however it is an issue persistent between reboots (also the user was added quite some time ago).
I also do not have a "groups" rather just /etc/group and /etc/group- which returns the same output as earlier:

cat /etc/group- | grep 'wheel'
wheel:x:998:USERNAME_REDACTED

"pkexec ls" does not return anything.

seth · 2022-06-04 20:14:51

pacman -Qo groups

https://archlinux.org/packages/core/x86_64/shadow/
=> /usr/bin/groups

"pkexec ls" should first and foremost trigger a password dialog and then (assuming you provide the password) run "ls" as root (os if the directory is empty, it'll indeed not print anything)

variable-root · 2022-06-04 21:37:38

sudo pacman -Qo groups
/usr/bin/groups is owned by shadow 4.11.1-1

cat /usr/bin/groups | grep 'wheel'

My mistake, I ran "pkexec ls" with sudo which returned nothing. I did this because running only "pkexec ls" then entering the password when prompted returned:

pkexec ls
Error executing command as another user: Not authorized

This incident has been reported.

It occurs to me now that the result of the command was not the point but to test whether the command could be run.

http://0x0.st/oM87.txt

Last edited by variable-root (2022-06-04 21:41:10)

seth · 2022-06-04 21:53:04

Please don't copy & paste out of the pager (or whatever you're doing there, it completely breaks lines) - rather redirect the output into a file and edit and upload that.
You entered the password into the KDE polkit dialog?

If you
1. pkill polkit-kde-authentication-agent-1 # kill the KDE polkit agent
2. echo $$ # obtain the PID of the current shell
3. pkttyagent --process 123456 # in a second terminal run thiw w/ 123456 being the PID of the first shell
4. pkexec ls # in the first terminal - the password will be requested in the second terminal where pkttyagent runs

Does that work?

variable-root · 2022-06-04 22:59:11

You entered the password into the KDE polkit dialog?

Yes, the result was the previous post.

Following the steps you listed:
terminal #1

echo $$
887
pkill polkit-kde-authentication-agent-1
pkexec ls

terminal #2

pkttyagent --process 887
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
Authentication is needed to run `/usr/bin/ls' as the super user
Authenticating as: USERNAME_REDACTED
Password: 
==== AUTHENTICATION COMPLETED ====

I have no idea how or why but it seems to be working now as I was able to alter my clock after these steps. Thank you for your help Seth.

Last edited by variable-root (2022-06-04 23:00:55)

seth · 2022-06-05 05:33:51

I assume the crucial bit was to kill the polkit agent which will have re-started it at some point. That's by accident.
The issue might re-surface.

The commands in #8 were mainly to understand whether it's a problem w/ the polkit infrastructure or the agent.
I see you figured that the order of actions was somewhat relevant ;-)

Does "hostnamectl" show a *static* hostname?
(Sidebar: hostname and username may have been embarrassing choices, but they're not security relevant - your WAN IP in combination w/ a public, password protected ssh login could be, but in that case: do not PW protect a WAN ssh login, use a private key)

Arch Linux

#1 2022-06-04 01:19:27

[SOLVED] Kde polkit permission issue

#2 2022-06-04 06:04:52

Re: [SOLVED] Kde polkit permission issue

#3 2022-06-04 15:58:41

Re: [SOLVED] Kde polkit permission issue

#4 2022-06-04 16:23:49

Re: [SOLVED] Kde polkit permission issue

#5 2022-06-04 17:48:27

Re: [SOLVED] Kde polkit permission issue

#6 2022-06-04 20:14:51

Re: [SOLVED] Kde polkit permission issue

#7 2022-06-04 21:37:38

Re: [SOLVED] Kde polkit permission issue

#8 2022-06-04 21:53:04

Re: [SOLVED] Kde polkit permission issue

#9 2022-06-04 22:59:11

Re: [SOLVED] Kde polkit permission issue

#10 2022-06-05 05:33:51

Re: [SOLVED] Kde polkit permission issue

Board footer