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 · Yesterday 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 (Yesterday 04:30:57)

seth · Yesterday 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?

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 Yesterday 03:36:09

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

#29 Yesterday 07:54:51

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

Board footer