Argh, I have a hunch that this broke with the authentication rework. Running "/usr/libexec/cockpit-desktop /" now shows that it's running in "Limited access mode", and there is no graphical polkit prompt any more. We somehow need to teach cockpit-desktop to try and do either the sudo or the polkit way when showing a particular frame already.

To confirm that this is indeed the bug you are seeing, please try this:

 - /usr/libexec/cockpit-desktop /
 - Click on the blue "Turn on administrative access mode" or the black "Limited access" in the top bar, and enter your sudo password.
 - Switch to Subscriptions

It should work then.

There is a minor but in subscription-manager that it doesn't correctly handle the case when an unprivileged user opens the page. But the main issue is with cockpit/cockpit-desktop itself, so I reassign this.

Fix and integration test are being developed in https://github.com/cockpit-project/cockpit/pull/14324 . It's not perfect yet, but we have an approach and a reproducer/test.

I can still reproduce this issue on latest cockpit

Issue: Observed the message "Retrieving subscription status"  displayed forever when tried to launch subscription manager from desktop by going to Activities --> Type "subscription-manager" click the cockpit wrapper window and launch the window .

[root@localhost ~]# rpm -qa cockpit
cockpit-224.1-1.el8.x86_64
[root@localhost ~]# 
[root@localhost ~]# subscription-manager version 
server type: Red Hat Subscription Management
subscription management server: 3.1.16-1
subscription management rules: 5.40
subscription-manager: 1.27.13-1.el8


adding additional info

[root@localhost ~]# /usr/libexec/cockpit-desktop /

(-c:16845): dbind-WARNING **: 17:21:37.155: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8sl2ZKcjc4: Connection refused
WaylandCompositor requires eglBindWaylandDisplayWL, eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer.
Nested Wayland compositor could not initialize EGL

(WebKitWebProcess:16853): dbind-WARNING **: 17:21:38.056: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-8sl2ZKcjc4: Connection refused
/bin/bash: line 1: 16841 Terminated              XDG_CONFIG_DIRS="$BROWSER_HOME" COCKPIT_SUPERUSER="pkexec" /usr/libexec/cockpit-ws -p 80 -a 127.0.0.90 --local-session=- 0<&0 1>&1
/usr/libexec/cockpit-desktop: line 1: 16832 Terminated              coproc COPROC ${2:+ssh "$2"} cockpit-bridge
[root@localhost ~]#

@Archana: What precisely happens when you use this command? Did you get a polkit prompt at all? With "/usr/libexec/cockpit-desktop /", did it show limited access mode or administrative mode? On my system, starting cockpit-desktop brings up a polkit prompt, then Cockpit is in administrative mode.

Created attachment 1712489 [details]
prompt seen on executing /usr/libexec/cockpit-desktop /

prompt seen on executing /usr/libexec/cockpit-desktop /

Archana and I looked at this on IRC. This is a completely unrelated problem: In that case cockpit-desktop already runs as root, so there is no polkit/limited access mode involved. Instead, the screenshot shows an empty browser window, so apparently at least in that installation webkit or something related is broken. Can you please file a new bugzilla about that?

I'm currently downloading/installing current RHEL 8.3 desktop to check this.

Leaving this bug at ON_QA then. Rehana, are you able to check this on current RHEL 8.3 to see if it works for you now?

FTR, Archana confirmed that this works with "BROWSER=firefox", so something in the webkit window is broken (that's the new bugzilla). But at least with firefox it now has administrative mode, and the polkit prompt worked, so it looks like *this* bug got fixed actually. *phew*. Thanks!

I finally have a current RHEL 8.3 desktop ("Server with GUI") install, with cockpit 224.2. When I launch "Subscriptions" from GNOME Activities, I now do get a polkit prompt (that's the cockpit part of this fix), and cockpit-bridge runs as root.

But the subscription-manager cockpit page still exhibits the forever-rotating "Retrieving subscription status" behaviour. I get exactly the same behaviour with opening a Terminal and running "/usr/libexec/cockpit-desktop subscriptions". I can also reproduce the empty window part of that bug with "/usr/libexec/cockpit-desktop /"

All pages work with BROWSER=firefox: Overview, subscriptions, storage, etc. It seems that the webkit window browser is somehow broken: It just renders the initial page, but never updates.

So the authentication part is fixed, the browser part isn't -- this still needs investigation.

Some observations:

 * This isn't related to the cockpit-desktop sandboxing/coproc stuff. Running the pywebkit browser against the normal http://localhost:9090 cockpit service has the same problem.

 * It is hard to get WebKit to catch console messages; WebkitWebPage has a "console-message-sent" signal [1], but I don't know how to get a WebPage from the top-level WebView object [2].
   However, I can call

      self.webview.get_settings().set_enable_write_console_messages_to_stdout(True)

   and that works.

 * Both epiphany-browser and my own pywebkit script (i. e. the one embedded in cockpit-desktop) work fine on Fedora 32. Both Fedora 32 and RHEL 8.3 have webkit 2.28.4, just Fedora is at revision -3, and RHEL at revision -1.

 * Unsetting $DISPLAY makes no difference -- so this really uses wayland in both cases. Conversely, forcing Xwayland (env -u WAYLAND_DISPLAY) also makes no difference.


I filed bug 1872270 against webkit for now, maybe the devs have an idea how to debug that.

[1] https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebPage.html#WebKitWebPage-console-message-sent
[2] https://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html

Contingency plan is to temporarily disable the webkit browser in cockpit-desktop. Then it will use firefox. But the user experience is really not great, as this really isn't a general "browser", and the extra default tab and all the chrome really gets in the way.

I guess this is probably pretty important, so I'll look into the WebKit bug soon.

(In reply to Martin Pitt from comment #13)
>  * It is hard to get WebKit to catch console messages; WebkitWebPage has a
> "console-message-sent" signal [1], but I don't know how to get a WebPage
> from the top-level WebView object [2].

WebKitWebPage is a web process object: there's no way to get it in the UI process. You have to write a web extension. You create a shared object that defines a WebKitWebExtensionInitializeFunction, that gets called on startup with a WebKitWebExtension, then you connect to its page-created signal to get each WebKitWebPage as it is created.

But forget about that, that's way too much effort to get some debug messages, especially when you've already discovered set_enable_write_console_messages_to_stdout(). That's better.

@Michael: Thanks, so I wasn't missing something obvious. But indeed set_enable_write_console_messages_to_stdout() seems to work -- I initially thought it didn't as I was getting so few messages, but it seems that's just a sign that the page loading hangs very early.

Created attachment 1712802 [details]
subscriptions desktop

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cockpit bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4511