Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2035781

Summary: gnome-software not handling error no-security for action refresh: Failed to obtain authentication
Product: Red Hat Enterprise Linux 9 Reporter: Jiri Prajzner <jprajzne>
Component: gnome-softwareAssignee: Milan Crha <mcrha>
Status: CLOSED NOTABUG QA Contact: Martin Krajnak <mkrajnak>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 9.0CC: klember, rhughes, tpelka, tpopela
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-03-10 18:06:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jiri Prajzner 2021-12-27 15:46:52 UTC
Description of problem:
software doesn't bring up the auth dialog and fails to list some categories.

Version-Release number of selected component (if applicable):
gnome-software-41.2-1.el9.x86_64

How reproducible:
always

Steps to Reproduce:
1. vncserver
2. gnome-software --display=:1
3.

Actual results:
15:40:52:0890 Gs  not handling error no-security for action refresh: Failed to obtain authentication.
15:40:52:0978 Gs  Only 0 apps for recent list, hiding
15:40:52:0992 Gs  failed to get featured apps: no apps to show
15:40:53:0060 Gs  Only 1 apps for popular list, hiding

journal:
PackageKit[41309]: uid 1001 is trying to obtain org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:0)
Dec 27 10:40:52 beaker-firefox-develop-1777 PackageKit[41309]: uid 1001 failed to obtain auth
Dec 27 10:40:52 beaker-firefox-develop-1777 gnome-shell[43013]: Can't update stage views actor MetaWindowGroup is on because it needs an allocation.
Dec 27 10:40:52 beaker-firefox-develop-1777 gnome-shell[43013]: Can't update stage views actor MetaWindowActorX11 is on because it needs an allocation.
Dec 27 10:40:52 beaker-firefox-develop-1777 gnome-shell[43013]: Can't update stage views actor MetaSurfaceActorX11 is on because it needs an allocation.

Expected results:
the security is handled correctly and categories listed properly

Additional info:

Comment 1 Milan Crha 2022-01-03 10:07:47 UTC
Thanks for a bug report. Do you run the gnome-software under that vncserver? I've no idea how these things work, but if the vncserver is somehow isolated from the rest of the system, then it makes sense PackageKit cannot authenticate. The authentication itself is on the PackageKit side, from which I believe this should be moved there, though I do not know whether there's anything to be done on the PackageKit side.

Comment 2 Jiri Prajzner 2022-01-14 17:16:20 UTC
(In reply to Milan Crha from comment #1)
> Thanks for a bug report. Do you run the gnome-software under that vncserver?
> I've no idea how these things work, but if the vncserver is somehow isolated
> from the rest of the system, then it makes sense PackageKit cannot
> authenticate. The authentication itself is on the PackageKit side, from
> which I believe this should be moved there, though I do not know whether
> there's anything to be done on the PackageKit side.

ssh to the machine, launched vncserver,ran gnome-software --display=:1, verified visually through vncviewer such as vinagre.
i'd expect the apps to behave the same as if i run them without the --display option. the vncserver is not a problem here, as the 
auth dialog appears if the apps run in the vnc session and not in the ssh session.

Comment 3 Milan Crha 2022-01-17 11:36:10 UTC
> the vncserver is not a problem here, as the auth dialog appears if the apps run in the vnc session and not in the ssh session.

I think that's it. The `--display` option only tells the application "draw me there, instead of here", but otherwise runs the application using the session it was started in. The ssh session may not have setup all needed services as a real GUI session, or even as the vncserver session (which does run more things, as a configured vncserver user?).

I do not think an expectation of "using --display is the same as running in that session" is correct. Again, I do not know how the vncserver works at all, but I understood from your comments that what you see supports my hypotheses.

When I try to reproduce this, then I see the vncserver itself runs its own gnome-software (use ps ax | grep gnome; mine shows one with --gapplication-service argument). It claims it's run on the same TTY, but otherwise it's not running under the same "session".

> 15:40:52:0890 Gs  not handling error no-security for action refresh: Failed to obtain authentication.

I do not see this error.

> 15:40:52:0978 Gs  Only 0 apps for recent list, hiding
> 15:40:52:0992 Gs  failed to get featured apps: no apps to show
> 15:40:53:0060 Gs  Only 1 apps for popular list, hiding

I do see these, but also when I run the gnome-software under the GNOME Session. It's expected, when there are configured only some repositories.

Comment 6 Milan Crha 2022-03-10 18:06:22 UTC
I'm closing this.

It's only vncserver related and the gnome-software is "a special application", which requires other services to run in the same memory space/D-Bus session, but the ssh does not have running everything the vncserver runs. Furthermore, the vncserver runs its own gnome-software, as expected. When a user tries to run gnome-software in a normal environment, then the background process (service) is woken up and shows a window - there are not running two gnome-software executables at the same time. It makes sense, because they would compete on the prepared updates, refresh of repositories and all those things, which touch system files. The gnome-software started from the ssh session doesn't know about the background service inside the vncserver, thus it cannot pass the execution to it.