Unable to open any software component which uses root authentication

MrWeatherbee · 2024-12-14 01:30:01

seth wrote:

So there's a collision ...

In the context of this issue, I take 'collision' to mean that the existence of 'polkit-gnome' on a system somehow interfered with the proper registration of the internal auth agent (leaving no agent running), thus failure to present a dialog. I definitely thought that was the failure point before my latest testing. Now, I am not sure that is happening (see previous post). I do not take 'collision' to mean the failure of a second auth agent to register if another is detected to be already running; that is just the way its supposed to work. I think we agree on that, but I wanted to be clear.

seth wrote:

clefebvre cannot reproduce this.

We know. Wish he could.

seth wrote:

2. nobody is at any point in any way, shape or form invoking sudo here, right? Don't!

No.

seth wrote:

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

The xinitrc file on the Virtual Machine is as simple as it gets (I've tried both of the exec statements with same results):

[[ -f ~/.Xresources ]] && xrdb -merge ~/.Xresources

#exec cinnamon-session-cinnamon
exec cinnamon-session

Everything else you pointed to was purposefully ignored for now.

seth · 2024-12-14 08:27:37

A collision in every context refers to n > 1 entities trying to occupy the same location at the same time, whether that's supposed to happen and gracefully handled or in someone calling an ambulance doesn't really matter
The point is: it's happening, just "where?"

The xinitrc file on the Virtual Machine is

broken and will result in a degenerated session w/o proper session bus integration.
I've limited hopes because this does typically not happen w/ lightdm sessions, but we should rule out that factor nevertheless.
See the last link below, 2nd blue note about what to include at least.
Then please post the resulting file and impact on the situation at hand.

Everything else you pointed to was purposefully ignored for now.

Not quite sure why, though.
If you're worried about your complete environment

printenv | sed "/DISPLAY\|XDG\|DBUS/\!d; s/${USER}/smurf/g"

will probably do.

MrWeatherbee · 2024-12-15 03:36:09

seth wrote:

The point is: it's happening, just "where?"

It seems that the alternative (internal agent properly registered but user names not detected, so failure) that I presented in the previous post is what is happening (see * below).

seth wrote:

The xinitrc file on the Virtual Machine is
broken ...

The VM runs exactly the same using the simple 'xinitrc' I posted as it does when the extra code (which sources /etc/X11/xinit/xinitrc.d) from the default xinitrc is added (if that was what you were referring to, I really could not tell for sure).

Here are some points:
- the issue with the latest version of Cinnamon persists in all scenarios; I have not experienced any issues prior to the Cinnamon update, and the only issue post-update is the topic-at-hand
- the output of printenv is exactly the same except for the additional ENV vars related to the 'libcanberra-gtk-module' and the 'xapp-gtk3-module' which appear when adding the extra code to xinitrc
- the output of ps aux | grep dbus is exactly the same in all scenarios except for timestamps, pids, etc.
- using 'exec cinnamon-session-cinnamon' or 'exec cinnamon-session' in the xinitrc makes no difference in functionality, and the output of the aforementioned commands is identical except for timestamps, pids, etc.

I appreciate your concern, and I'll probably update the xinitrc at some point. Since I am satisfied for now that it did not help the current Cinnamon issue to change it, I'm going to leave it as presented for now just for consistency.

=====

* I was able to get the auth agent dialog box to present on the VM (I have not tried the same thing on other PCs yet). I achieved this by modifying the file:

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

in such a way that forced (hard-coded) all variables to contain values of the data that I thought was missing but required by the auth agent dialog. It was not a fun.

However, I think it proves that the auth agent is getting properly registered (no 'collision', graceful or otherwise ), but the code that follows registration fails every time it tries to query system data or put the data to use. What I've done still does not solve anything, because I am getting no indication as to why the code cannot successfully query and obtain the required data. As I said in an earlier post, Cinnamon has other widgets and desktop elements that present, without issue, the exact same information that the auth agent requires but can't get. I did notice that at least some of the code was originally written around 2011 and seems to have been recycled from their earlier flirtation with using their own internal auth agent.

Here's a screenshot (it's real, I promise):
Cinnamon Internal Auth Agent Dialog Box

Edit:

A few extra points:
- the xinitrc used in the experiment that produced the dialog box was the basic one I presented in an earlier post
- I originally did not click on any of the auth agent dialog buttons to see what would happen; I was afraid I wouldn't be available to make these posts if I did: I sensed an explosion; however
- After a break, I looked more closely at the dialog's functionality:
> The dialog properly displays its sub-header as 'Files' (it was launched via Nemo's 'Open as root' context-menu item)
> the password input field works
> the button to view the password works
> the 'Authenticate' button is initially dimmed, and activates / brightens when characters are input into the password field
> the 'Cancel' button works

Last edited by MrWeatherbee (2024-12-15 04:30:57)

seth · 2024-12-15 07:54:51

However, I think it proves that the auth agent is getting properly registered

That is what wa proven by the collision w/ the gnome agent - "collision" doesn't always mean "car crash"

if that was what you were referring to

Yes.
Does it change anything about the polkit agent interface actually showing up on the session bus?

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

in such a way that forced (hard-coded) all variables to contain values of the data that I thought was missing but required by the auth agent dialog. It was not a fun.

Did you post the diff on the upstream bug?

MrWeatherbee · 2024-12-20 00:15:44

The bug has been closed on GitHub.

The bug, however, was not fixed.

The changes to the code, albeit probably helpful in other cases by making the code more robust, were at best tangential to the issue and seem to have been based on Gnome bug reports dating back to 2012.

The new / added code does this:

Code Update 1. dont' crash if there is no avatar
Code Update 2. don't crash if the internal agent can't be registered

Code Update 2, above, includes a nice warning message to the user that the internal auth-agent could not be registered.

As I said previously, the issue in this forum discussion and reported on GitHub does not manifest as the internal auth-agent failing to register.

It does register, and as such, the warning message that was added to the new code does not ever present itself.

Following is the sequence of code events that occurs with the the 'real' bug (just reiterating info from previous posts):

> the polkit auth-agent registers successfully
> the code, unrelated to registering, runs when required (via user interaction) and attempts to collect the user data needed to present the Dialog box and elevate privileges
> the code fails because the data it was trying to collect is not collected and results in a critical JS error: the arguments where the data is stored must not be NULL

The Dialog box never appears, not because the agent did not register, but because the arguments to code that runs (after the registration) are required and cannot be NULL.

I do not expect the Cinnamon devs (or any devs) to perform miracles in cases where they cannot duplicate the issue, so it's obviously fair to close the bug, especially if proper diligence was exercised before doing so.

However, I am not sure I agree with closing a bug with code-commits where the commits give the impression that they 1) are relevant to the reported bug, and 2) fixed the bug, neither of which is the case (and, of course the dev could not know one way or the other because he did not duplicate the issue). Again, I am not saying the changes are without merit, but maybe it would have been more appropriate just to include them in generic code-base changes as opposed to committing them with reference to a specific bug.

Thanks.

seth · 2024-12-20 09:33:14

I don't like that the service doesn't show up in your session bus and apparently there's no API to query what agents are actually registered.
Let's see what pids *are* on the bus, maybe some overzealous agent is secretly blocking the spot…

#!/bin/bash
BUS="session"
if [ "$1" = "--system" ]; then
    BUS="system"
    shift
fi

listpids() {
    while read OBJ; do
        dbus-send --${BUS} --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID 'string:'"$OBJ" | sed '/uint32/!d; s/^\s*uint32 //g'
    done < <(dbus-send --${BUS} --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames | sed '/string/!d; s/^\s*string //g; s/"//g')
}

while read PID; do
    printf "%8s : " $PID
    cat /proc/$PID/comm
done < <(listpids)

passing "--system" as parameter will check the system bus.

Arch Linux

#26 2024-12-14 01:30:01

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

#27 2024-12-14 08:27:37

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

#28 2024-12-15 03:36:09

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

#29 2024-12-15 07:54:51

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

#30 2024-12-20 00:15:44

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

#31 2024-12-20 09:33:14

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

Board footer