Summary: | Don't try to fetch updates if such a privilege isn't granted | ||
---|---|---|---|
Product: | [Applications] muon | Reporter: | Pierre Ossman <ossman> |
Component: | notifier | Assignee: | Jonathan Thomas <echidnaman> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | aleixpol, bhush94, kde, plasma-bugs, rdieter, sitter |
Priority: | NOR | ||
Version: | 5.5.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Pierre Ossman
2015-12-28 09:26:41 UTC
As you put it, it's mostly a PackageKit error. What would you like us to do there? PackageKit doesn't do anything unless you invoke something from your application. I haven't dug around its API, but it may unfortunately be that you have to hold off on refreshing updates until user action. Under which circumstances? We want to be able to see if there's upgrades... I understand that. But what if that's not possible without nagging unprivileged users to death? If PackageKit lacks such an API then this will be a case of the lesser evil. Can you show us the default permissions on org.freedesktop.packagekit.system-sources-refresh I understand, you can always remove the plasmoid though. It doesn't serve any purpose in a system without privileges to upgrade. (In reply to David Edmundson from comment #5) > Can you show us the default permissions on > org.freedesktop.packagekit.system-sources-refresh They are: <defaults> <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> <allow_active>yes</allow_active> </defaults> (from https://github.com/hughsie/PackageKit/blob/master/policy/org.freedesktop.packagekit.policy.in) Remote sessions fall under the "any" category and it was changed from "no" to "auth_admin" here: https://github.com/hughsie/PackageKit/commit/4888afef339ec8472cf800b3e696f03631b1031e (In reply to Aleix Pol from comment #6) > I understand, you can always remove the plasmoid though. It doesn't serve > any purpose in a system without privileges to upgrade. I figured as much. But as a vendor I'm more concern about the defaults that everyone else will see, and what their experience will be. This is not a good out-of-box experience IMO. And to be honest, it's far from obvious how to fix this. Clicking on "Software updates" doesn't give any options to disable it. (Btw, is muon really the correct component here? I have no muon packages installed on this system.) As a vendor, you should be able to easily set the defaults, no? (yes, muon is the correct component, we're reorganizing). Sorry, I should have been clearer there. :) I'm working for a vendor of remote access software, not the distribution. The users will have to get the base OS (and KDE) the normal way. So I could file bugs with Red Hat, Canonical, Debian, etc. But going as far upstream as possible seemed like a more efficient way. :) I'll see what I can do. Do you know of an easy way to reproduce? That would greatly help to provide a fix. Easiest way to test is to change your <allow_active> to auth_admin As for fixing Kauth should report back whether auth is required or not in ::status() Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved. Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved. |