Password issue with Muon Package Manager

[claydoh]

We are kinda forgetting that Muon is basically unmaintained, and for quite some time now. I am kinda surprised it is still in the default install.
It is easy for something like this to not be discovered, if not many people actually test things (few do), or report things to the QA tracker (even fewer). Reduce this even further if no one is actually using Muon to access the Software Sources tool, since it is also accessible from Discover.
Also, have upgrades even been turned on yet, for non-LTS upgrades? I haven't booted my 21,10 box in a bit...

[arsivci]

I guess this only shows up on systems that do an upgrade instead of a fresh install? Seems a bit silly that such a bug managed to pass beta, since it's not just happening on some random software. I also did an in-place upgrade to 22.04, so maybe they just didn't test that. Either way, I have grown to expect these little "quirks" with each Kubuntu release. Eventually they get fixed.

Fresh install, here but it is affected nonetheless.

[Melcar]

We are kinda forgetting that Muon is basically unmaintained, and for quite some time now. I am kinda surprised it is still in the default install.
It is easy for something like this to not be discovered, if not many people actually test things (few do), or report things to the QA tracker (even fewer). Reduce this even further if no one is actually using Muon to access the Software Sources tool, since it is also accessible from Discover.
Also, have upgrades even been turned on yet, for non-LTS upgrades? I haven't booted my 21,10 box in a bit...

This is not a Muon issue as it happens in other applications too (the ones that spawn a root window). Discover also has this issue by the way (and Discover is not really a good replacement for Muon or Synaptic). The only way to access software sources or change your software sources with a GUI is to use a terminal to launch the window or Synaptic.

[rab0171610]

For anyone that did not see this it a newer post about the same issue I am reposting it here. This may or may not help but it is a suggestion of things to check to make sure they are set up properly. I cannot confirm this on my Kubuntu box as my first upgrade did not go well and I had to do a clean reinstall with a usb stick, I am not having this issue. I can only confirm how it is setup on a working installation of Jammy. It may not even be the issue but it is just something to check:

This could possibly be an issue with the upgrade itself. When installing KDE in Gentoo, the user has to manually make it so that root permission dialogs such as grub-customizer and package managers will work correctly. This is set up automatically in Kubuntu. But I suggest checking this to make sure that it does not solve your problem.

Per the Gentoo KDE wiki:

[QUOTE
Non-root user authentication for dialogs
Some KDE dialogs such as printers, adding wireless networks and adding users require administrator authentication. This is handled through polkit and operates independently from sudo. By default in Gentoo, the root account is the only administrator, and so even if a user account can run root commands through sudo, authentication in these KDE dialogs will fail.

Adding wireless networks using networkmanager is allowed by a polkit rule which is part of the Gentoo package and already allows access for every user in the group plugdev. For other dialogs you need to configure the behavior manually: If you would like all users of the group wheel to be administrators, create a copy of /etc/polkit-1/rules.d/50-default.rules starting with a number lower than 50, and edit the line return ["unix-user:0"] to the following:

FILE: /etc/polkit-1/rules.d/49-wheel.rules

polkit.addAdminRule(function(action, subject) {
return ["unix-group:wheel"];

});

That being said, I don't think Kubuntu uses a wheel group. The equivalent is sudo and admin I believe.
There are two files in Kubuntu that provide a similar function:

/etc/polkit-1/localauthority.conf.d/50-localauthority.conf

and

/etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf

I would just first verify that you have both of these files:

ls -al /etc/polkit-1/localauthority.conf.d/

which should return something like this:
total 16
drwxr-xr-x 2 root root 4096 Mar 25 03:34 .
drwxr-xr-x 4 root root 4096 Mar 25 03:33 ..
-rw-r--r-- 2 root root 267 Feb 26 06:11 50-localauthority.conf
-rw-r--r-- 2 root root 65 Feb 26 06:11 51-ubuntu-admin.conf

Secondly, I would verify that 50-localauthority.conf contains only this:

[Configuration]
AdminIdentities=unix-user:0

Then, confirm 51-ubuntu-admin.conf says only this:

[Configuration]
AdminIdentities=unix-group:sudo;unix-group:admin

I would also verify that the groups sudo and admin actually exist on the system:

groups

which should return a list of all groups on the system.

And lastly, I would make sure the affected user is indeed in the admin and sudo groups:

id username

or

groups username

where username is replaced by the login name of the user affected
This should return a list of groups that the user belongs to. If not in the sudo or admin group they can be added with:

sudo usermod -a -G sudo,admin username

where username is replaced by the actual login name of the user. Changes will not take effect until the user has logged out and logged back in again.

This may or may not be an issue for you but it would not hurt to check.


Good Luck!

[wonder]

I guess this only shows up on systems that do an upgrade instead of a fresh install? Seems a bit silly that such a bug managed to pass beta, since it's not just happening on some random software. I also did an in-place upgrade to 22.04, so maybe they just didn't test that. Either way, I have grown to expect these little "quirks" with each Kubuntu release. Eventually they get fixed.

Both on updated computers and fresh install.
I tried both options and seeing some small bugs after updating I opted to do a fresh install.
The "surprise" was that an update is just as good as a fresh install...

[Melcar]

Both on updated computers and fresh install.
I tried both options and seeing some small bugs after updating I opted to do a fresh install.
The "surprise" was that an update is just as good as a fresh install...

Upgrades do work, and generally well enough. The trick is to do them from a terminal and examine all of the prompts you get with along the process and not just accept defaults. This is the third release I upgrade in this way.

[NoWorries]

I have this exact problem with other programs that launch a root window as well. Grub Customizer, ksystemlog, unetbootin are the ones where I have encountered this. Some programs work fine however, like kde partition manager and gsmartcontrol. I hope this gets fixed. Upgraded from Kubuntu 21.10.

I have had this problem with these packages and what I do is use Konsole and enter for say muon: sudo muon. If this is unwise to do and can cause problems, please let me know. So far I have not had any problems.

[Melcar]

I have had this problem with these packages and what I do is use Konsole and enter for say muon: sudo muon. If this is unwise to do and can cause problems, please let me know. So far I have not had any problems.

Yeah, it works that way. It also works for any other program that has this issue. Have not tried launching them with krunner yet.

[jlittle]

sudo muon. If this is unwise to do and can cause problems...

In principle, running any GUI app as root, unless it is designed to do that (such apps isolate the privileged component) is a security risk and can cause permissions problems in your home directory. What a GUI might do is open-ended; theming, messages, writing settings... there's many possibilities. Even displaying a font can be used for privilege escalation.

I suggest that using sudo -i to get a root shell first, then run muon. Then, any settings files written or GUI actions invoked will be those from root's home directory (which is /root). I'm sure there'll still be security concerns, but they're lessened I think.

[NoWorries]

In principle, running any GUI app as root, unless it is designed to do that (such apps isolate the privileged component) is a security risk and can cause permissions problems in your home directory. What a GUI might do is open-ended; theming, messages, writing settings... there's many possibilities. Even displaying a font can be used for privilege escalation.

I suggest that using sudo -i to get a root shell first, then run muon. Then, any settings files written or GUI actions invoked will be those from root's home directory (which is /root). I'm sure there'll still be security concerns, but they're lessened I think.

Thanks very much for that insight. I only use sudo for muon when I want to change settings which is not very often.

[acheron]

Interestingly, if you downgrade the sudo package to the version found in impish 21.10, this then works. Not in any way advising anyone to do that!

[rab0171610]

Has anyone checked to see if sudo/wheel and KDE policykit are set up correctly?

[bendy]

Just bumping this to confirm that I applied the latest updates today on my test laptop, and this problem still exists.....

[acheron]

The issue is this bug in debian: https://bugs.debian.org/cgi-bin/bugr...gi?bug=1011624

and this in KDE: https://bugs.kde.org/show_bug.cgi?id=452532

[Snowhog]

The issue is this bug in debian: https://bugs.debian.org/cgi-bin/bugr...gi?bug=1011624

Thank-you for that! I applied your workaround.