Bug 1355862

Summary: make glib clients handle dconf permissions more gracefully
Product: Red Hat Enterprise Linux 7 Reporter: Ben Woodard <woodard>
Component: glib2Assignee: Colin Walters <walters>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: tgummels, tpelka, tumeya
Target Milestone: rcKeywords: FutureFeature
Target Release: 7.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-15 07:30: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:
Bug Depends On:    
Bug Blocks: 1593423, 1891032    

Description Ben Woodard 2016-07-12 18:54:00 UTC
Description of problem:
we had a configuration management problem due to umask that set the permissions of a glib scheme. This lead to every gnome client crashing due to a segv.

Version-Release number of selected component (if applicable):
Up to date RHEL7.2 release 

How reproducible:
Always


Steps to Reproduce:
# Do this as root
upgrade2 /g/g0/py# umask 077; umask; glib-compile-schemas /usr/share/glib-2.0/schemas 2> /dev/null; ls -l /usr/share/glib-2.0/schemas/gschemas.compiled
0077
-rw-------. 1 root root 169821 Jul  1 11:51 /usr/share/glib-2.0/schemas/gschemas.compiled
 
# Run this as you
upgrade2 ~> printf "run\nbt\n" | gdb -q /usr/bin/gnome-calculator
Reading symbols from /usr/bin/gnome-calculator...Reading symbols from /usr/bin/gnome-calculator...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install gnome-calculator-3.14.1-2.el7.x86_64
(gdb) Starting program: /usr/bin/gnome-calculator 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
 
** (gnome-calculator:18215): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-dzEtcxfjnB: Connection refused
Detaching after fork from child process 18222.
[New Thread 0x2aaab62f0700 (LWP 18223)]
 
(gnome-calculator:18215): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
 
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00002aaaad4048c3 in g_logv () from /lib64/libglib-2.0.so.0
(gdb) #0  0x00002aaaad4048c3 in g_logv () at /lib64/libglib-2.0.so.0
#1  0x00002aaaad404a3f in g_log () at /lib64/libglib-2.0.so.0
#2  0x00002aaaabd8db43 in g_settings_set_property () at /lib64/libgio-2.0.so.0
#3  0x00002aaaacc0c629 in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#4  0x00002aaaacc0e1d4 in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#5  0x00002aaaacc0e5d1 in g_object_new () at /lib64/libgobject-2.0.so.0
#6  0x0000000000411ea4 in calculator_real_startup ()
#7  0x00002aaaacc07067 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#8  0x00002aaaacc1fb27 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#9  0x00002aaaacc2077f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#10 0x00002aaaabd783ba in g_application_register () at /lib64/libgio-2.0.so.0
#11 0x00002aaaabd78b6f in g_application_real_local_command_line () at /lib64/libgio-2.0.so.0
#12 0x00002aaaabd78e6b in g_application_run () at /lib64/libgio-2.0.so.0
#13 0x0000000000412695 in calculator_main ()
#14 0x00002aaaadc2ab15 in __libc_start_main (main=
    0x4112d0 <main>, argc=1, ubp_av=0x7fffffffdb88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdb78)
    at libc-start.c:274
#15 0x0000000000411315 in _start ()
(gdb) quit
A debugging session is active.
 
	Inferior 1 [process 18215] will be killed.
 
Quit anyway? (y or n) [answered Y; input not from terminal]

Actual results:
segv

Expected results:
Some sort of graceful handling of the lack of the configuration information. In this case dealing with the fact that it can't get the configuration schema could be as simple as printing a reasonable error message. Or just being able to deal with 


Additional info:
This seems to affect all glib applications not just gnome-calculator
This continues to be a problem up and through the latest fedora 23

Here is a backtrace from F23
(gnome-calculator:13790): GLib-GIO-ERROR **: No GSettings schemas are installed on the system

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff545786b in _g_log_abort (breakpoint=1) at gmessages.c:324
324	    G_BREAKPOINT ();
Missing separate debuginfos, use: dnf debuginfo-install gvfs-client-1.26.3-1.fc23.x86_64 libcanberra-0.30-10.fc23.x86_64 libcanberra-gtk3-0.30-10.fc23.x86_64 libogg-1.3.2-4.fc23.x86_64 libtdb-1.3.9-1.fc23.x86_64 libtool-ltdl-2.4.6-8.fc23.x86_64 libvorbis-1.3.4-5.fc23.x86_64 PackageKit-gtk3-module-1.0.11-1.fc23.x86_64
(gdb) bt
#0  0x00007ffff545786b in g_logv (breakpoint=1) at gmessages.c:324
#1  0x00007ffff545786b in g_logv (log_domain=0x7ffff5a968f8 "GLib-GIO", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=args@entry=0x7fffffffd510) at gmessages.c:1081
#2  0x00007ffff54579df in g_log (log_domain=log_domain@entry=0x7ffff5a968f8 "GLib-GIO", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x7ffff5ab5c68 "No GSettings schemas are installed on the system")
    at gmessages.c:1119
#3  0x00007ffff5a50cf2 in g_settings_set_property (object=0x555555a51b00 [GSettings], prop_id=<optimized out>, value=<optimized out>, pspec=<optimized out>) at gsettings.c:585
#4  0x00007ffff5754f03 in g_object_new_internal (nqueue=0x5555558a03a0, value=<optimized out>, pspec=0x555555a34070 [GParamString], object=0x555555a51b00 [GSettings]) at gobject.c:1420
#5  0x00007ffff5754f03 in g_object_new_internal (class=class@entry=0x55555590b5b0, params=params@entry=0x7fffffffd790, n_params=n_params@entry=1) at gobject.c:1813
#6  0x00007ffff5756a15 in g_object_new_valist (object_type=object_type@entry=93824995559616, first_property_name=first_property_name@entry=0x7ffff5ab67cb "schema-id", var_args=var_args@entry=0x7fffffffd8e0)
    at gobject.c:2038
#7  0x00007ffff5756d81 in g_object_new (object_type=93824995559616, first_property_name=0x7ffff5ab67cb "schema-id") at gobject.c:1622
#8  0x0000555555560e76 in calculator_real_startup (base=0x5555557d2140 [Calculator]) at gnome-calculator.c:292
#9  0x00007ffff574f9d4 in _g_closure_invoke_va (closure=closure@entry=0x5555557c0ba0, return_value=return_value@entry=0x0, instance=instance@entry=0x5555557d2140, args=args@entry=0x7fffffffdc80, n_params=<optimized out>, param_types=0x0) at gclosure.c:864
#10 0x00007ffff576a2bd in g_signal_emit_valist (instance=0x5555557d2140, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffdc80) at gsignal.c:3292
#11 0x00007ffff576a8ff in g_signal_emit (instance=instance@entry=0x5555557d2140, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3439
#12 0x00007ffff5a3aec2 in g_application_register (application=application@entry=0x5555557d2140 [Calculator], cancellable=cancellable@entry=0x0, error=error@entry=0x7fffffffddc0) at gapplication.c:2015
#13 0x00007ffff5a3b647 in g_application_real_local_command_line (application=0x5555557d2140 [Calculator], arguments=0x7fffffffdeb8, exit_status=0x7fffffffdeb4) at gapplication.c:983
#14 0x00007ffff5a3b98a in g_application_run (application=0x5555557d2140 [Calculator], argc=1, argv=0x7fffffffe018) at gapplication.c:2280
#15 0x0000555555561693 in calculator_main (args=0x7fffffffe018, args_length1=1) at gnome-calculator.c:1150
#16 0x00007ffff4304580 in __libc_start_main (main=
    0x555555560230 <main>, argc=1, argv=0x7fffffffe018, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe008) at libc-start.c:289
#17 0x0000555555560279 in _start ()
(gdb)

Comment 1 Ben Woodard 2016-07-12 19:18:54 UTC
I guess it is not a segv.

The code that is failing is:

(gdb) up
#3  0x00007ffff5a50cf2 in g_settings_set_property (object=0x555555a51b00 [GSettings], prop_id=<optimized out>, 
    value=<optimized out>, pspec=<optimized out>) at gsettings.c:585
585	              g_error ("No GSettings schemas are installed on the system");
(gdb) list
580	
581	            g_assert (settings->priv->schema == NULL);
582	            default_source = g_settings_schema_source_get_default ();
583	
584	            if (default_source == NULL)
585	              g_error ("No GSettings schemas are installed on the system");
586	
587	            settings->priv->schema = g_settings_schema_source_lookup (default_source, schema_id, TRUE);
588	
589	            if (settings->priv->schema == NULL)
(gdb)

Comment 2 Ben Woodard 2016-07-12 19:47:41 UTC
Instead of g_error'ing out could apps have an embedded default schema that it can fall back to if it can't access a local schema.

Comment 4 Colin Walters 2016-07-12 20:41:18 UTC
There's limits to how defensive we can make the system against random commands being run as root against /usr.

In particular it was a design choice to require functional schema, because otherwise each application needs *another* copy of the the schema which is a waste of space.

So your best bet is to fix the config management system.

Comment 5 Ben Woodard 2016-07-13 06:05:47 UTC
After discussing this with the customer about appropriate behavior, he said that they really have no problem with the program exiting the problem was with the use of g_error which ultimately calls abort.

In particular he cited the g_error() documentation:

{quote}
A convenience function/macro to log an error message.

This is not intended for end user error reporting. Use of GError is preferred for that instead, as it allows calling functions to perform actions conditional on the type of error.

Error messages are always fatal, resulting in a call to abort() to terminate the application. This function will result in a core dump; don't use it for errors you expect. Using this function indicates a bug in your program, i.e. an assertion failure.

If g_log_default_handler() is used as the log handler function, a new-line character will automatically be appended to @..., and need not be entered manually.
{quote}

To me this sounds like a defensible position. His suggestion is to change the g_error to g_critical and then immediately exit thus avoiding the abort and the core dump.

Comment 10 RHEL Program Management 2021-02-15 07:30:50 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.