Assertion failure due to repeated K5_KEY_GSS_SPNEGO_STATUS registration.

[Adam Dabrowski]

Hello,

Sequence of events:

1. Libgssapi_krb.so.2.2 is loaded dynamically with dlopen.
2. Call to gss_init_sec_context - library initialization, first 
registration of K5_KEY_GSS_SPNEGO_STATUS.
3. libgssapi_krb.so.2.2 is unloaded, however libkrb5support stays in the 
process memory.
4. Steps 1., 2..
5. Abort due to failed assertion 'destructors_set[keynum] == 0' in 
k5_key_register.

Stack trace:

#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f592ba0842a in __GI_abort () at abort.c:89
#2  0x00007f592b9ffe67 in __assert_fail_base (fmt=<optimized out>,
     assertion=assertion at entry=0x7f58f14ac80f "destructors_set[keynum] 
== 0", file=file at entry=0x7f58f14ac7c1 "threads.c",
     line=line at entry=353, function=function at entry=0x7f58f14ac930 
<__PRETTY_FUNCTION__.5126> "krb5int_key_register") at assert.c:92
#3  0x00007f592b9fff12 in __GI___assert_fail 
(assertion=assertion at entry=0x7f58f14ac80f "destructors_set[keynum] == 0",
     file=file at entry=0x7f58f14ac7c1 "threads.c", line=line at entry=353,
     function=function at entry=0x7f58f14ac930 <__PRETTY_FUNCTION__.5126> 
"krb5int_key_register") at assert.c:101
#4  0x00007f58f14a7d57 in krb5int_key_register 
(keynum=keynum at entry=K5_KEY_GSS_SPNEGO_STATUS, 
destructor=destructor at entry=0x0)
     at threads.c:353
#5  0x00007f58f1de7c10 in gss_spnegoint_lib_init () at spnego_mech.c:314
#6  0x00007f58f1dc2805 in gssint_mechglue_init () at g_initialize.c:127
#7  gssint_mechglue_init__aux () at g_initialize.c:102
#8  0x00007f592c61e759 in __pthread_once_slow 
(once_control=0x7f58f1ffab70 <gssint_mechglue_init.once>,
     init_routine=0x7f58f1dc27d0 <gssint_mechglue_init__aux>) at 
pthread_once.c:116
#9  0x00007f592c61e805 in __GI___pthread_once 
(once_control=once_control at entry=0x7f58f1ffab70 <gssint_mechglue_init.once>,
     init_routine=<optimized out>) at pthread_once.c:143
#10 0x00007f58f14a7a11 in k5_once (once=once at entry=0x7f58f1ffab70 
<gssint_mechglue_init.once>, fn=<optimized out>) at threads.c:562
#11 0x00007f58f1dc6ec7 in gssint_mechglue_initialize_library () at 
g_initialize.c:164
#12 0x00007f58f1dc7755 in gssint_select_mech_type 
(minor=minor at entry=0x7f58dc067654, oid=0x7f5929f47ed0,
     selected_oid=selected_oid at entry=0x7f58f2ffc8c8) at g_initialize.c:1009
#13 0x00007f58f1dc2541 in gss_init_sec_context 
(minor_status=0x7f58dc067654, claimant_cred_handle=0x0, 
context_handle=0x7f58dc067658,
     target_name=0x7f58dc07eff0, req_mech_type=<optimized out>, 
req_flags=34, time_req=0, input_chan_bindings=0x0, input_token=0x0,
     actual_mech_type=0x0, output_token=0x7f5929f484d8 <gss_+88>, 
ret_flags=0x7f58f2ffc95c, time_rec=0x0) at g_init_sec_context.c:145

The obvious question is why libkrb5support is not unloaded with 
libgssapi_krb5?
One scenario on which I came across, is when localauth interface plugin 
is used. All it takes is to specify localauth_test.so
as localauth plugin in krb5.conf to reproduce this behaviour. My best 
guess is that plugin's dependence on libkrb5support increases
it's reference count within process, which prevents it's unloading 
during dlclose call on libgssapi_krb5. Regardless of the reasons
for which libkrb5support stays in memory, it seems to me that the 
problem could be solved by adding k5_key_delete(K5_KEY_GSS_SPNEGO_STATUS)
and perhaps some other necessary cleanup to gss_spnegoint_lib_fini 
function, as it's done for kerberos mech in gss_krb5int_lib_fini.
I can confirm that spnego key deletion prevents assertion failure during 
subsequent libgssapi_krb5 reloads, but I'm not sure if
this is proper/sufficient solution.

I also suspect that this report referring to assertion failure during 
key registration might have occurred under similar circumstances:

https://krbdev.mit.edu/rt/Ticket/Display.html?id=8614

/Adam