Bug 357245 - Don't try to fetch updates if such a privilege isn't granted
Summary: Don't try to fetch updates if such a privilege isn't granted
Status: REPORTED
Alias: None
Product: muon
Classification: Applications
Component: notifier (show other bugs)
Version: 5.5.0
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Jonathan Thomas
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-28 09:26 UTC by Pierre Ossman
Modified: 2021-03-10 00:12 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Ossman 2015-12-28 09:26:41 UTC
Logging in using ThinLinc (or any other remote session) in KDE on Fedora 23 pops up an authentication request for "refresh the system resources". This is most likely fallout from the PackageKit commit 4888afef. Similar bugs are present in Gnome components:

https://bugzilla.gnome.org/show_bug.cgi?id=751776
https://bugzilla.gnome.org/show_bug.cgi?id=751775

The permission in question is "org.freedesktop.packagekit.system-sources-refresh" and seems to be triggered by the update notification function in Plasma.

This is for plasma-workspace-5.5.0-4.fc23.x86_64

It also keeps retrying now and then causing an error to keep popping up. Very user unfriendly. :/
Comment 1 Aleix Pol 2015-12-29 12:59:01 UTC
As you put it, it's mostly a PackageKit error. What would you like us to do there?
Comment 2 Pierre Ossman 2015-12-29 13:06:40 UTC
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.
Comment 3 Aleix Pol 2015-12-29 15:15:17 UTC
Under which circumstances? We want to be able to see if there's upgrades...
Comment 4 Pierre Ossman 2015-12-29 15:43:16 UTC
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.
Comment 5 David Edmundson 2015-12-29 15:48:05 UTC
Can you show us the default permissions on org.freedesktop.packagekit.system-sources-refresh
Comment 6 Aleix Pol 2015-12-29 15:52:24 UTC
I understand, you can always remove the plasmoid though. It doesn't serve any purpose in a system without privileges to upgrade.
Comment 7 Pierre Ossman 2015-12-30 10:37:49 UTC
(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.)
Comment 8 Aleix Pol 2015-12-30 13:18:12 UTC
As a vendor, you should be able to easily set the defaults, no?

(yes, muon is the correct component, we're reorganizing).
Comment 9 Pierre Ossman 2015-12-30 14:23:57 UTC
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. :)
Comment 10 Aleix Pol 2016-01-02 02:24:04 UTC
I'll see what I can do. Do you know of an easy way to reproduce? That would greatly help to provide a fix.
Comment 11 David Edmundson 2016-01-02 02:28:41 UTC
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()
Comment 12 Justin Zobel 2021-03-10 00:10:53 UTC
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.
Comment 13 Justin Zobel 2021-03-10 00:12:37 UTC
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.