[16444] in Kerberos-V5-bugs
[krbdev.mit.edu #8863] krb5int_key_delete: Assertion
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Fri Jan 10 02:20:28 2020
From: "Greg Hudson via RT" <rt@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-4.4.4-68095-1578629625-1371.8863-5-0@mit.edu>
Message-ID: <rt-4.4.4-52665-1578640822-316.8863-5-0@mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #8863":;
Date: Fri, 10 Jan 2020 02:20:22 -0500
MIME-Version: 1.0
Reply-To: rt@KRBDEV-PROD-APP-1.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
<URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8863 >
There are some theoretically possible execution paths along those lines that
could lead to the assertion failure, but they don't seem likely to be the cause
of the assertion failures you're seeing.
I don't think the interruption scenario is plausible. SIGKILL would abort the
process immediately (no library unloading), as would any unhandled signal. If a
signal arrived, was handled, and the handler returned, the initializer would
continue running and would finish registering all of the keys. Signal handlers
are not allowed to call exit(). Signal handlers are allowed to call _exit(),
but that would bypass library unloading. On top of that, the "graceful reload
or restart" operation would not seem likely to send a signal to processes while
they are in the middle of initializing the GSSAPI library.
The failed initializer scenario actually kind of tracks, because of a bug in
gssint_mechglue_init() (
https://github.com/krb5/krb5/blob/master/src/lib/gssapi/mechglue/g_initialize.c#L106
) where error values can be ignored. (If errors were correctly handled, the
INITIALIZER_RAN() guard in gssint_mechglue_fini() would not consider the
initializer to have run because it returned an error.) But I don't think this
is a likely scenario for two reasons. First, you say you're not using krb5, and
gssint_mechglue_init() doesn't actually run until a GSSAPI function is invoked.
(It's possible that the PHP module invokes a GSSAPI function when it starts up,
I guess.) Second, failures inside gss_krb5int_lib_init() should be vanishingly
uncommon; one doesn't really expect mutex initialization to fail.
I will fix the bug in gssint_mechglue_init(), but to diagnose the actual
problem with any confidence, either I need to be able to reproduce the problem,
or someone who reliably sees the problem needs to debug it in situ, likely by
adding a bunch of instrumentation to the initializer and finalizer code.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
