Bug 1873297
| Summary: | Gnome-software coredumps when run as root in terminal | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Bill Sanford <bsanford> | ||||||
| Component: | gnome-software | Assignee: | Milan Crha <mcrha> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Krajnak <mkrajnak> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 8.3 | CC: | klember, mboisver, mcatanza, mkrajnak, rhughes, rstrode, tpelka, tpopela | ||||||
| Target Milestone: | rc | Keywords: | Triaged | ||||||
| Target Release: | 8.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | gnome-software-3.36.1-7.el8 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2021-11-09 19:33:50 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: | |||||||||
| Attachments: |
|
||||||||
Instead of a core dump, I was expecting something similar: gnome-software Unable to init server: Could not connect: Connection refused 17:46:10:0047 Gtk cannot open display: This is also happening in F32. No GTK programs should be run as root. Downloading and parsing files from the public internet should never be done as root, and running GTK under X is also insecure in various ways. (In reply to Bill Sanford from comment #0) > Created attachment 1712870 [details] > backtrace for core dump Please use gdb to take the backtrace (e.g. 'coredumpctl gdb'). This thing from abrt isn't enough information to solve the crash. Created attachment 1712962 [details]
coredump of segfault
Loaded gdb and got the bt of the newest coredump
(gdb) bt
#0 0x00005654018c0b70 in gs_shell_search_provider_setup (provider=0x0, loader=<optimized out>)
at ../src/gs-shell-search-provider.c:400
#1 0x000056540189575c in gs_application_setup_search_provider (app=0x565402e70130) at ../src/gs-application.c:884
#2 0x000056540189575c in gs_application_startup (application=0x565402e70130) at ../src/gs-application.c:957
#3 0x00007fbf530c53bd in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#4 0x00007fbf530d8a94 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#5 0x00007fbf530e1a06 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#6 0x00007fbf530e2043 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#7 0x00007fbf52a9c492 in g_application_register () at /lib64/libgio-2.0.so.0
#8 0x0000565401893229 in gs_application_handle_local_options (app=0x565402e70130, options=0x565402e82300)
at ../src/gs-application.c:1044
#9 0x00007fbf4eb7b09e in ffi_call_unix64 () at /lib64/libffi.so.6
#10 0x00007fbf4eb7aa4f in ffi_call () at /lib64/libffi.so.6
#11 0x00007fbf530c6386 in g_cclosure_marshal_generic_va () at /lib64/libgobject-2.0.so.0
#12 0x00007fbf530c5616 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#13 0x00007fbf530e1485 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#14 0x00007fbf530e2043 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#15 0x00007fbf52a9caaf in g_application_real_local_command_line () at /lib64/libgio-2.0.so.0
#16 0x00007fbf52a9d053 in g_application_run () at /lib64/libgio-2.0.so.0
#17 0x000056540188a628 in main (argc=1, argv=0x7fff08d6e648) at ../src/gs-main.c:48
So we're crashing in startup calling gs_shell_search_provider_setup() because app->search_provider is unexpectedly NULL. That's set in dbus_register and cleared in dbus_unregister. dbus_unregister will be called immediately after dbus_register if dbus_register fails. It's also possible that dbus_register is not called at all if earlier D-Bus calls fail inside g_application_impl_attempt_primary() (gapplicationimpl-dbus.c). Either way, we reach startup with app->search_provider == NULL. Avoiding this particular crash would be easy because we could just not initialize the search provider. I wouldn't expect gnome-software to actually work if the session bus is not functioning properly, though.... I filled this upstream at [1] and provided a possible fix. I do think checking for non-NULL is okay in this case. [1] https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1142 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 (Moderate: GNOME security, 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/RHSA-2021:4381 |
Created attachment 1712870 [details] backtrace for core dump Description of problem: Running the "gnome-software" command as root results in a Segmentation fault and core dump. Version-Release number of selected component (if applicable): gnome-software-3.36.1-4 How reproducible: 100% Steps to Reproduce: 1. Type gnome-software, as root, in terminal. 2. 3. Actual results: Segmentation fault (core dump). Expected results: Additional info: