Unable to open any software component which uses root authentication

sidambhire · 2024-12-10 02:13:32

Dear Arch Linux community,
I have cinnamon DE. Whenever I try to open anything that requires root authentication, it doesn't work. Cannot mount volumes in nemo. Cannot unlock LUKS partition on SSD in gnome-disks. Cannot open 'Users and Groups' setting in settings.

Here's output of `sudo journalctl -b | curl -F 'file=@-' 0x0.st`.

Please help!

Scimmia · 2024-12-10 02:22:33

Have you tried it without security=apparmor? And what are noquiet nosplash supposed to do.

You also seem to have network issues, why is dhcpcd enabled if you're using NM?

sidambhire · 2024-12-10 02:34:58

I tried without security=apparmor, it didn't fix the issue.

noquiet and nosplash are for displaying kernel messages while booting.

dhcpd is enabled because I forgot to disable it, I'm a noob.

Scimmia · 2024-12-10 03:36:15

sidambhire wrote:

noquiet and nosplash are for displaying kernel messages while booting.

Pretty sure they're not. AFAIK, they don't do anything at all.

What did you do during that log that didn't work? It's difficult to wade through all of the NM and dhcpcd fighting to see what happened, would be easier if we knew what we were looking for.

seth · 2024-12-10 09:27:09

https://wiki.archlinux.org/title/Polkit … ion_agents
It looks a bit like you're running cinnamon, is its polkit agent running?

loginctl session-status

sidambhire · 2024-12-10 18:34:22

loginctl session-status

This command showed it's status as active.

sidambhire · 2024-12-10 22:18:46

Scimmia wrote:

What did you do during that log that didn't work? It's difficult to wade through all of the NM and dhcpcd fighting to see what happened, would be easier if we knew what we were looking for.

Here's what I get after disabling dhcpcd.

seth · 2024-12-10 22:28:38

The idea was more whether it would show any polkit agent - which doesn't seem to be the case?
Try to install polkit-gnome - the wiki asserts that cinnamon comes w/ its own polkit agent, but w/ https://github.com/linuxmint/cinnamon/pull/12272 and https://github.com/linuxmint/cinnamon/issues/10172 I'm not sure that's actually true.

sidambhire · 2024-12-11 02:13:44

seth wrote:

Try to install polkit-gnome

It was already installed. I also tried reinstalling it (as well as polkit). It didn't work.

seth · 2024-12-11 07:32:33

What happens if you manually run /usr/libexec/polkit-gnome-authentication-agent-1 ?

MrWeatherbee · 2024-12-11 18:57:12

After updating my system on 20241209, I encountered similar / related issues with the authorization agent and with 'pkexec' not running (i.e., not launching the authorization / password dialog).

I first noted the behavior when I attempted to use the 'Open As Root' option in Nemo file manager. Clicking on the option apparently did nothing.

I initially thought it was related to the 'cinnamon' updates (dated 20241209), but when I tested some of my bash scripts that use 'pkexec', the same failure to launch the password dialog occurred.

I went off on a tangent for a while looking into 'pam' and 'polkit', but eventually shifted back to focusing on 'cinnamon'. At that point, I tested downgrading 'cinnamon' in an Arch virtual machine (downgraded from 6.4.2-1 -> 6.2.9-1), and 'pkexec' began working again. Please note that I did not downgrade all cinnamon-related packages, just 'cinnamon' itself. As a result of the partial downgrade, the 'cinnamon' desktop was not quite stable, but it did prove the relationship between the 'cinnamon' package update and the issues at hand.

Some observations:

1) With version 6.4.2-1, any time the system attempts to launch the password dialog via 'pkexec', it hangs and does nothing. This can be observed when checking system processes where 'pkexec' is listed with a PID. If 'pkexec' is run from a terminal, the hang is clearer as the prompt never returns for further input until killed by the user.

2) With version 6.4.2-1, running 'loginctl session-status | grep polkit' returns nothing but with version 6.2.9-1, the following is returned (as expected): '[PID] /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1'.

3) With version 6.4.2-1, trying to run '/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1' from the command-line returns the error:
Cannot register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject.
However, I cannot figure out what authentication agent that message is referencing. With version, 6.2.9-1, after manually killing the 'polkit-gnome' process, it can be relaunched from the command-line without complaint.

-----
Some discussion of the use of polkit authorization by the Cinnamon devs and the changes made as of version 6.4:
https://github.com/linuxmint/cinnamon/issues/10172 - already mentioned by Seth
https://github.com/linuxmint/cinnamon/pull/12272 - already mentioned by Seth
https://github.com/linuxmint/cinnamon/pull/12549

Based on the information linked above, especially Issue 12549, it seems possible that something is incorrectly assessing whether another authorization agent is running.

However, I have not seen a bug report over there yet specifically calling out this issue. I generally give these minor-inconvenience issues (in my assessment; it may be quite different for other users) a couple of days to see if updates are issued to resolve the problem before I login to Github to report (I'm getting quite lazy in this regard as I get older). This seems like such an 'in-your-face' problem, however, that those guys have to know about it; but maybe not.

-----
edit: add links to Github discussion / activity

Last edited by MrWeatherbee (2024-12-11 20:22:03)

seth · 2024-12-11 21:29:36

dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID 'string:'"org.freedesktop.PolicyKit1.AuthenticationAgent" | sed '/uint32/!d; s/^\s*uint32 //g'

should™ print the PID of the polkit agent process.

dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames | sed '/string/!d; s/^\s*string //g'

will print all session bus interfaces

sidambhire · 2024-12-11 23:53:28

seth wrote:

What happens if you manually run /usr/libexec/polkit-gnome-authentication-agent-1 ?

I found it here: /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1

This was the error message
Cannot register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: An authentication agent already exists for the given subject

sidambhire · 2024-12-11 23:58:19

MrWeatherbee wrote:

Based on the information linked above, especially Issue 12549, it seems possible that something is incorrectly assessing whether another authorization agent is running.
However, I have not seen a bug report over there yet specifically calling out this issue. I generally give these minor-inconvenience issues (in my assessment; it may be quite different for other users) a couple of days to see if updates are issued to resolve the problem before I login to Github to report (I'm getting quite lazy in this regard as I get older). This seems like such an 'in-your-face' problem, however, that those guys have to know about it; but maybe not.
-----
edit: add links to Github discussion / activity

Thanks for the detailed analysis of the bug. It is very much important to me because I have to mount an encrypted LUKS partition and only root can do it. This bug should be reported.

Edit: Filed a bug report.

Last edited by sidambhire (2024-12-12 00:16:09)

MrWeatherbee · 2024-12-12 03:52:13

@sidambhire

Thank you for taking the time to submit the bug report.

@seth

I ran the commands you provided in both the virtual machine (where Cinnamon was downgraded and 'pkexec' was working) and in my main installation (where Cinnamon is current and 'pkexec' is not working).

For the first command, the output was the same in both cases:

Error org.freedesktop.DBus.Error.NameHasNoOwner: The connection does not exist

So, that really did not divulge anything useful.

Note that I also ran the command with '--system' instead of '--session' with the same results, and I modified 'org.freedesktop.PolicyKit1.AuthenticationAgent' to variants such as 'org.freedesktop.PolicyKit1.Authority', 'org.freedesktop.PolicyKit1' , etc. without yielding anything that could help identify an unknown running authorization agent (or a known one for that matter).

The second command (the one that lists the bus interfaces) was also run as '--session' and '--system'. The named interfaces that were listed were not related to polkit, but in playing with 'Bustle' and 'dbus-monitor', I could see that the numeric ids that were listed (e.g., :1.22) in some cases may have been related.

The output of the program, 'dbus-monitor', was interesting to watch, but ultimately it was only producing PIDs for 'polkit.caller-pid' ('pkexec') and 'polkit.subject-pid' ('nemo', in this case) when clicking on the 'Open As Root' menu-item in Nemo. I was never able to observe anything that was pointing to the exact identity of an authorization agent (even in the case where it was clear, and observable by other means, that one was running); in other words, there was no way of telling, as far as I could see, which, if any, authorization agent was running on a given system by observing DBus communications. There may be a way, but I do not know enough about Polkit or DBus to get any further with this pursuit.

Anyway, thanks for your help. Hopefully the Cinnamon devs get it fixed or point us to what needs to be done to get it working again.

seth · 2024-12-12 04:55:55

Ftr: cinnamon depends on https://archlinux.org/packages/extra/x8 … kit-gnome/ the interface is org.freedesktop.PolicyKit1.AuthenticationAgent
There's /usr/share/cinnamon/js/ui/polkitAuthenticationAgent.js which exists for a while and recently saw some heavy action, https://github.com/linuxmint/cinnamon/c … onAgent.js - you could try to revert the last two

MrWeatherbee · 2024-12-12 13:32:19

seth wrote:

Ftr: cinnamon depends on https://archlinux.org/packages/extra/x8 … kit-gnome/ the interface is org.freedesktop.PolicyKit1.AuthenticationAgent
There's /usr/share/cinnamon/js/ui/polkitAuthenticationAgent.js which exists for a while and recently saw some heavy action, https://github.com/linuxmint/cinnamon/c … onAgent.js - you could try to revert the last two

Yes. The dependency on 'polkit-gnome', the desire to remove the dependency, and the steps and timeline to be used in removing the dependency are what was / is being discussed in most of the links that both you and I provided.

The question is, in the attempt to move away from the dependency and create their own auth agent, what got overlooked / broken?

To be honest, based on the discussion in the GitHub links, and the resulting observed behavior of Cinnamon 6.4.2, I was surprised to see that 'polkit-gnome' is still listed as a dependency in the PKGBUILD for cinnamon 6.4.2-1.

Anyway, I'll reiterate:
- with Cinnamon 6.2.9-1 (which worked fine as did all previous versions that I have used), 'polkit-gnome' is automatically started and functions normally, allowing 'pkexec' to provide a dialog box when tasked to do so. In 6.2.9-1, 'polkit-gnome' (/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1) can be observed running in the background using process-exploring tools. If 'polkit-gnome' is killed, it can easily be restarted without throwing any errors.

- with Cinnamon 6.4.2-1 (which does not work fine for me and the OP), 'polkit-gnome' is not automatically started (and I think this is correct if they now provide their own auth agent), and when a manual attempt to start it is performed, it throws an error and does not run. Something is preventing it from registering, presumably Cinnamon's new code, and that would be fine if 'pkexec' functioned correctly but it does not ('pkexec' hangs and no authorization / password dialog is presented to the user).

It's very possible that some remnant(s) of our set-ups is not compatible with the new code, and all that is required is some set-up changes on our end. We'll see.

Anyway, thanks again.

seth · 2024-12-12 18:01:21

It's very possible that some remnant(s) of our set-ups is not compatible with the new code, and all that is required is some set-up changes on our end. We'll see.

Test the behavior w/ a fresh user account.
As mitigation you should be able to explicitly start polkit-gnome-authentication-agent-1 ahead of cinnamon (so it'll take and block the dbus interface)

MrWeatherbee · 2024-12-12 22:57:55

I had some time to look through the file:

/usr/share/cinnamon/js/ui/polkitAuthenticationAgent.js

specifically at the parts where the dialog was being built and initiated.

Obviously, we are having issues with auth agent registration, and when I found a line in the code that looked related (Line 488), there was also a //TODO attached to it:

        // TODO - maybe register probably should wait until later, especially at first login?
        this._native.register();

Without really understanding the code fully enough yet to know how to complete the //TODO, I simply commented-out the line:

        // TODO - maybe register probably should wait until later, especially at first login?
        //this._native.register();

I restarted Cinnamon (now upgraded to 6.4.2-1 for this test, the version that did not work for me and the OP), and I was able to use 'polkit-gnome' again as my auth agent jsut as in 6.2.9-1. and Looking Glass is not showing any errors.

Even if a solution is found to get Cinnamon's internal auth agent working, I may use this (or another way) to bypass the native Cinnamon agent. I can't really tell for sure because obviously I have not seen it appear on my computers yet, but the picture of it posted by a dev over on GitHub seems to suggest that some functionality (the Details button) has been removed. The Detail info comes in handy sometimes.

My hack obviously is not what was intended by the Cinnamon devs, but I was simply trying things out and digging a little deeper because the 'BUG' status was summarily dismissed over on GitHub. It looks like sidambhire is now getting some help, but I was a little disappointed in the initial response.

-----
edit: fixed paragraph spacing

Last edited by MrWeatherbee (2024-12-12 23:15:18)

MrWeatherbee · 2024-12-12 23:39:57

@sidambhire

Just out of curiosity, how are you logging in to Cinnamon?

I'm not using a graphical login, I use xinitrc.

Nevermind: I can see from your loginctl output you are using 'lightdm'.

Last edited by MrWeatherbee (2024-12-12 23:59:27)

sidambhire · 2024-12-13 00:58:12

MrWeatherbee wrote:

        // TODO - maybe register probably should wait until later, especially at first login?
        //this._native.register();

This also fixed the bug for me. Thanks @MrWeatherbee. I think we need to inform cinnamon developers.

MrWeatherbee · 2024-12-13 05:33:11

sidambhire wrote:

This also fixed the bug for me. Thanks @MrWeatherbee. I think we need to inform cinnamon developers.

You're welcome.

But, just to be clear: this is NOT a bug fix. Certainly not one that can be accepted by the Cinnamon devs.

This is a BYPASS of Cinnamon's internal (and for us), non-functioning authorization agent.

What I hoped to demonstrate with this (especially to myself) was that once the Cinnamon agent is neutered (even with a very minimal change to their code), all the other Polkit-related components return to normal functioning condition. And as far as I can tell at this point, there are no side effects to this.

By the way, did I understand correctly that the Cinnamon devs thought you were logging in as root? I must be misunderstanding what they were suggesting / asking. I certainly am not logging in to a DE as root, and I have the same problem as you do. Also, if logging in as root, why would we need to elevate privileges to root using an auth agent. And who normally changes the name of their root account (is that a thing)? I definitely am confused by those posts over there.

seth · 2024-12-13 09:11:51

So there's a collision (blocking the cinnabun agent from the bus allows the gnome agent to connect), but the interface doesn't show up in your session bus.
org.freedesktop.policykit.exec is recorded by the cinnabun agent but no dialog shows up.
clefebvre cannot reproduce this.

1. Do you get the behavior w/ a fresh user account
2. nobody is at any point in any way, shape or form invoking sudo here, right? Don't!
3. What's the output of

ps aux | grep dbus
printenv

4. @MrWeatherbee - do I need to ask for your xinitrc or do you import the environment into the session bus and there's also no dbus-launch anywhere

Curveball: try to "export NO_AT_BRIDGE=1" to the session. For whatever reason the at-spi (a11y feature, orca etc) uses its own bus. This just completely disables the gtk a11y stuff.

MrWeatherbee · 2024-12-14 00:09:27

Update:

I put several logging commands in the file:

/usr/share/cinnamon/js/ui/polkitAuthenticationAgent.js

and uncommented the auth agent registration code for this test.

- From the logging, I see this relevant info at login (remember, I'm using .xinitrc, so no auth dialogs are required during this process):
1) code in 'function init' is run;
2) code in 'var AuthenticationAgent' is run:
> [ constructor ] - code before auth agent registration
> [ constructor ] - auth agent registration (this._native.register();)
> [ constructor ] - code after auth agent registration

Note - does this mean that the authorization agent successfully registered as the code continued to run after registration? Also, I definitely didn't expect to see this code run during login (again, since I am using xinitrc). The result also seems to go against the 'collision' theory if it indeed registered successfully, but does fit with the fact that attempting to launch another auth agent results in an error. Its just not as obvious that the javascript auth agent is running as it is when using 'polkit-gnome' (the latter is easily found in process explorers).

- From the logging, I see this info when attempting to elevate privileges (in this case, running Nemo's 'Open As Root' menu-option):
1) code in 'var AuthenticationAgent' is run:
> [ _onInitiate ] - output: 'userNames' appears to be an 'array' with only 1 element [root]
2) code in 'var AuthenticationDialog' is run:
> [ updateUser ] - output: 'user' is an object whose properties '_userName' and '_realName' are both null

If it is correct that the auth agent successfully registered, then I think the next theory is that failure to present the dialog is caused by an inability of the code to ascertain the user(s) name(s) (something the dialog requires but is missing). There is an error message coded in the file, but it apparently does not get processed.

The results may also be why the Cinnamon dev is so interested in what sidambhire's user name is and why he jumped to the conclusion that sidambhire was running as root (sidambhire states he was not).

I think it may be helpful if one of the devs supplied a test script to run using similar, but simplified, code to test what might being going on when attempting to get the user(s) name(s). I know that some other code in Cinnamon has ascertained my user name because, in the most obvious instance, it is presented on the panel bar immediately after login. So I am not sure why the auth agent code can't get it.

Finally, I could be way off since my javascript skills are basically nil, I'm just wasting an hour here and there digging around. I do not like javascript and never bothered to learn it. When I hear the word 'javascript', my brain immediately jumps to browsers and apps presenting ads and slurping up user-data, not desktop environments.

-----
edit: punctuation / typo

Last edited by MrWeatherbee (2024-12-14 00:13:13)

seth · 2024-12-14 00:34:46

The agent probably automatically registers when cinnamon starts - regardless how (there's nothing special about xinit itr)

The result also seems to go against the 'collision' theory if it indeed registered successfully, but does fit with the fact that attempting to launch another auth agent results in an error

"that attempting to launch another auth agent results in an error" /is/ "the 'collision' theory", the question is where that collision happens if the interface does indeed not show up on the session bus.

Does "_ensureOpen()" ever run?
Does "_onSessionRequest(session, request, echoOn)"?

What about the environment and dbus instances?

Arch Linux

#1 2024-12-10 02:13:32

Unable to open any software component which uses root authentication

#2 2024-12-10 02:22:33

Re: Unable to open any software component which uses root authentication

#3 2024-12-10 02:34:58

Re: Unable to open any software component which uses root authentication

#4 2024-12-10 03:36:15

Re: Unable to open any software component which uses root authentication

#5 2024-12-10 09:27:09

Re: Unable to open any software component which uses root authentication

#6 2024-12-10 18:34:22

Re: Unable to open any software component which uses root authentication

#7 2024-12-10 22:18:46

Re: Unable to open any software component which uses root authentication

#8 2024-12-10 22:28:38

Re: Unable to open any software component which uses root authentication

#9 2024-12-11 02:13:44

Re: Unable to open any software component which uses root authentication

#10 2024-12-11 07:32:33

Re: Unable to open any software component which uses root authentication

#11 2024-12-11 18:57:12

Re: Unable to open any software component which uses root authentication

#12 2024-12-11 21:29:36

Re: Unable to open any software component which uses root authentication

#13 2024-12-11 23:53:28

Re: Unable to open any software component which uses root authentication

#14 2024-12-11 23:58:19

Re: Unable to open any software component which uses root authentication

#15 2024-12-12 03:52:13

Re: Unable to open any software component which uses root authentication

#16 2024-12-12 04:55:55

Re: Unable to open any software component which uses root authentication

#17 2024-12-12 13:32:19

Re: Unable to open any software component which uses root authentication

#18 2024-12-12 18:01:21

Re: Unable to open any software component which uses root authentication

#19 2024-12-12 22:57:55

Re: Unable to open any software component which uses root authentication

#20 2024-12-12 23:39:57

Re: Unable to open any software component which uses root authentication

#21 2024-12-13 00:58:12

Re: Unable to open any software component which uses root authentication

#22 2024-12-13 05:33:11

Re: Unable to open any software component which uses root authentication

#23 2024-12-13 09:11:51

Re: Unable to open any software component which uses root authentication

#24 2024-12-14 00:09:27

Re: Unable to open any software component which uses root authentication

#25 2024-12-14 00:34:46

Re: Unable to open any software component which uses root authentication

Board footer