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.

MrWeatherbee · 2025-02-10 12:17:49

Hello again.

Yesterday, I was digging around in 'dconf-editor' unrelated to this issue, and for some reason I decided to do a search for 'Polkit'. To my surprise, there was an entry that allowed Enabling / Disabling the Cinnamon polkit agent.

I couldn't really believe that setting was available back when this topic was hot, so I checked on GitHub to see when the code was committed. Turns out it was added on Dec. 19, 2024, the same day that the Cinnamon dev closed the bug report. Here is the commit:
https://github.com/linuxmint/cinnamon/c … 750231bb5c

In closing the bug report, the dev mentioned 2 commits that were not helpful at all in my estimation (I discussed them in an earlier post), but he did not mention adding the ability to disable their Polkit agent, which, of course, was / is helpful. But, it's only helpful if you know about it.

Now that we know, there is no longer a need to manually modify the javascript file as I described in this post:
https://bbs.archlinux.org/viewtopic.php … 2#p2214032

Just change the setting using 'dconf-editor', or from the command-line:
Disable

dconf write /org/cinnamon/enable-polkit-agent "false"

Enable

dconf write /org/cinnamon/enable-polkit-agent "true"

If you manually edited the /usr/share/cinnamon/js/ui/polkitAuthenticationAgent.js to disable the Cinnamon polkit agent, you need to revert those changes as they are not necessary anymore. If you added Cinnamon to your pacman ignore-list because of this issue (i.e., you did not want an update overwriting your file edits), you probably need to revert that, too.

Once the setting is modified, you'll need to log out and back in (or reboot?), and then, if you have disabled the Cinnamon agent, the non-Cinnamon polkit agent will once again be functional.

This is an interesting feature for me, even though I got the original issue sorted out, because I prefer the non-Cinnamon polkit agent.

Now let me present the ACTUAL fix, at least in my case(s), if you want to use the Cinnamon polkit agent. It's very simple:

 gpasswd -a USER_NAME GROUP_NAME

where GROUP_NAME=wheel

That's it.

And here is why the code failed / fails:
1) It assumes that everyone that had been relying on an agent (for years) that elevates privileges using ROOT (no need to be a member of WHEEL), would automatically know that the replacement agent now elevates using the user's password (requiring the user to be a member of WHEEL);
2) There are no tests in the code to determine if the only Admin user is root. It simply drops the ball. If it doesn't find a regular user that is a member of WHEEL, forget it.

Item 2 is why I was able to get the Auth Dialog to appear by hard-coding my username throughout the code, and why it fails if a username is not present. Once you add your user to WHEEL, it gets the username it needs and everything works. Basically, if the only Admin user it finds is ROOT, which is what happens when no regular users are part of WHEEL, it bails with no soft landing.

I added this code to /usr/share/cinnamon/js/ui/polkitAuthenticationAgent.js to simulate what I think should happen instead of just letting the code fail ungracefully:

_onInitiate(nativeAgent, actionId, message, iconName, cookie, userNames) {
    // My
    global.log(userNames);
    let numUsers = userNames.length;
    global.log(numUsers);
    if (numUsers <= 1) {
       if (userNames[0] = 'root') {
          global.log('No users in wheel group');
          global.log('Disabling Cinnamon Polkit Agent');
          global.settings.set_boolean("enable-polkit-agent", false);
       }
    }

The code successfully sends messages to the Looking Glass Console when it can't find a suitable user and then disables the Polkit agent via its dconf setting. After logging out / logging back in, the non-Cinnamon agent is again available to the user.

The above code snippet, if done correctly and completely, would:
1) need to test for userNames[0] = Null as well, but I did not have a quick / easy way to simulate such a case, so I did not include it (I think it's way edge, if not impossible, anyway);
2) need to be placed at a different point in the code, preferably before ever registering the Cinnamon agent (again, I bring up the fact that there is a note in the code that suggests that delaying the registration until later might be good, and I think what they had in mind was that it needed to wait until they were sure they could get an array of 'regular' Admin users);
3) need to present the messaging to the user via a dialog as opposed to Looking Glass, because no one is going to see Looking Glass output (messaging could include what went wrong, suggested fix, a link to a help document, etc.);
4) need to call the cancel / complete function to cleanup.

And, I really think the Nemo context menu item, Open as Root, needs to be changed to something more appropriate like Open as Admin.

However it's done, a way to fail gracefully absolutely needs to be in the code. There is just no way you can assume everyone is going to have their user as part of WHEEL, then just dump and slink off if they don't.

Finally, I wonder if there should have been code in the Cinnamon PKGBUILD to automatically add the user to WHEEL, or preferably, just add a note in the install script that the user now needs to be part of WHEEL to use the Cinnamon agent.

Note 1 - big thanks to the folks / Cinnamon users over on GitHub who opened up another Bug Report on this (or similar) issue (that hasn't been closed, believe it or not). There has been little-to-no activity from the devs, but the bug report has zeroed in on the idea that WHEEL is the deal. Some of the things they suggested were, I believe, more complicated than ultimately is required to get things working. But close enough. I'm not sure everyone has bought in yet, but I ran with it, and it worked for me. Your mileage may vary.

Note 2 - I am still not going to be participating over at GitHub, but at least one of the posts over there linked to my workaround of editing the javascript to disable the Cinnamon agent. The participants in that new bug report, as far as I can tell, are unaware of the new ability to toggle the agent via dconf, and I'm sure that would be interesting to some of them. So, sidambhire, if you are intrigued enough by the new info to pop back over to GitHub and participate, maybe the Cinnamon folks can finally conclude this. Thanks.

https://github.com/linuxmint/cinnamon/issues/12620

Note 3 - by the way, I did some testing in VBox using Cinnamon's Settings -> Users And Groups to change a user from 'Standard' to 'Admin' (their terminology), and in using it, two entries were modified in /etc/group:

wheel:x:10:root       ->   wheel:x:10:root,mrweatherbee
mrweatherbee:x:1000:  ->   mrweatherbee:x:1000:mrweatherbee

The first mod, which adds the user to WHEEL, makes sense to me. The second mod, I do not get. Why would you need to add yourself to your self-named group, when your primary group is likely already your self-named group? I know that these modifications are not 100% related to the functionality of the Cinnamon polkit agent since the ability to manage users and groups via a GUI may be desirable to some people regardless. It just seems odd, especially since the only change that was required to get the Cinnamon polkit agent working was adding the user to WHEEL. I rolled back the changes in VBox and then manually added the user to WHEEL via command-line without doing anything else, and the polkit agent worked fine thereafter. Somebody added that entry for some reason, but it wasn't to set things up correctly for the Cinnamon polkit agent, so I'm curious why that would be a thing. Thanks.

--
edit: added remark about context menu.
edit: added Note 3.

Last edited by MrWeatherbee (2025-02-10 13:12:03)

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

#32 2025-02-10 12:17:49

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

Board footer