[20187] in Kerberos_V5_Development
Assertion failure due to repeated K5_KEY_GSS_SPNEGO_STATUS
daemon@ATHENA.MIT.EDU (Adam Dabrowski)
Thu Oct 15 17:49:35 2020
From: Adam Dabrowski <adabrowski@nomachine.com>
To: <krbdev@mit.edu>
Message-ID: <2e40edd7-1774-2ba2-ee8d-aef68658177b@nomachine.com>
Date: Thu, 15 Oct 2020 23:49:16 +0200
MIME-Version: 1.0
Content-Language: en-GB
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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@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@entry=0x7f58f14ac80f "destructors_set[keynum]
== 0", file=file@entry=0x7f58f14ac7c1 "threads.c",
line=line@entry=353, function=function@entry=0x7f58f14ac930
<__PRETTY_FUNCTION__.5126> "krb5int_key_register") at assert.c:92
#3 0x00007f592b9fff12 in __GI___assert_fail
(assertion=assertion@entry=0x7f58f14ac80f "destructors_set[keynum] == 0",
file=file@entry=0x7f58f14ac7c1 "threads.c", line=line@entry=353,
function=function@entry=0x7f58f14ac930 <__PRETTY_FUNCTION__.5126>
"krb5int_key_register") at assert.c:101
#4 0x00007f58f14a7d57 in krb5int_key_register
(keynum=keynum@entry=K5_KEY_GSS_SPNEGO_STATUS,
destructor=destructor@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@entry=0x7f58f1ffab70 <gssint_mechglue_init.once>,
init_routine=<optimized out>) at pthread_once.c:143
#10 0x00007f58f14a7a11 in k5_once (once=once@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@entry=0x7f58dc067654, oid=0x7f5929f47ed0,
selected_oid=selected_oid@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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
