SEGV in krb5_free_cred_contents on Opensolaris
Markus Moeller
huaraz at moeller.plus.com
Sun Nov 1 14:28:54 EST 2009
It looks like a OpenSolaris bug as I found in rel_cred.c the following
special MEMORY cache handling. Would it make sense to check in
krb5_free_cred_contents if val is != NULL ?
61 /*
62 * Solaris Kerberos
63 * If the ccache is a MEMORY ccache then this credential handle
64 * should be the only way to get to it, at least until the advent
65 * of a GSS_Duplicate_cred() (which is needed and may well be
66 * added some day). Until then MEMORY ccaches must be destroyed,
67 * not closed, else their contents (tickets, session keys) will
68 * leak.
69 */
70 if (strcmp("MEMORY", krb5_cc_get_type(context, cred->ccache)) ==
0)
71 code1 = krb5_cc_destroy(context, cred->ccache);
72 else
73 code1 = krb5_cc_close(context, cred->ccache);
Markus
"Markus Moeller" <huaraz at moeller.plus.com> wrote in message
news:hckmuv$iik$1 at ger.gmane.org...
>I got a bit further in identifying where the pointer is reset. It looks
>like
> the sasl library frees the memory cache. Strangely enough I don't see
> this
> behaviour with a file cache on OpenSolaris nor on a Linux platform.
>
> Any idea ?
>
> Thank you
> Markus
>
> (gdb) where
> #0 krb5_mcc_free (context=0x8930fc0, id=0x88e0d90) at
> ../krb5/ccache/cc_memory.c:182
> #1 0xd226a307 in krb5_mcc_destroy (context=0x8930fc0, id=0x88e0d90) at
> ../krb5/ccache/cc_memory.c:214
> #2 0xd226c7b4 in krb5_cc_destroy (context=0x8930fc0, cache=0x88e0d90) at
> ../krb5/ccache/ccfns.c:55
> #3 0xd21e641f in krb5_gss_release_cred (minor_status=0x8022520,
> cred_handle=0x8022534) at
> /src/build/usr/src/lib/gss_mechs/mech_krb5/mech/rel_cred.c:71
> #4 0xd21eb50f in krb5_gss_init_sec_context (minor_status=0x802268c,
> claimant_cred_handle=0x0, context_handle=0x88d3734, target_name=0x88c6990,
> mech_type=0xd1a08308, req_flags=42, time_req=0, input_chan_bindings=0x0,
> input_token=0x0, actual_mech_type=0x0, output_token=0x8022694,
> ret_flags=0x8022674, time_rec=0x0) at
> /src/build/usr/src/lib/gss_mechs/mech_krb5/mech/init_sec_context.c:997
> #5 0xd21e3eec in k5glue_init_sec_context (ctx=0x0,
> minor_status=0x802268c,
> claimant_cred_handle=0x0, context_handle=0x88d3734, target_name=0x88c6990,
> mech_type=0xd1a08308, req_flags=42, time_req=0, input_chan_bindings=0x0,
> input_token=0x0, actual_mech_type=0x0, output_token=0x8022694,
> ret_flags=0x8022674, time_rec=0x0) at
> /src/build/usr/src/lib/gss_mechs/mech_krb5/mech/krb5_gss_glue.c:843
> #6 0xd27451c8 in gss_init_sec_context () from /usr/lib/libgss.so.1
> #7 0xd19f41d3 in ?? ()
> #8 0x0802268c in ?? ()
> #9 0x00000000 in ?? ()
> #10 0x088e3d6c in ?? ()
> #11 0x088d3cd8 in ?? ()
> #12 0xd1a08308 in ?? ()
> #13 0x0000002a in ?? ()
> #14 0x00000000 in ?? ()
> #15 0x00000000 in ?? ()
> #16 0x00000000 in ?? ()
> #17 0x00000000 in ?? ()
> #18 0x08022694 in ?? ()
> #19 0x08022674 in ?? ()
> #20 0x00000000 in ?? ()
> #21 0x00000000 in ?? ()
> #22 0x00000000 in ?? ()
> #23 0xd1a0834c in ?? ()
> #24 0xd1f79000 in ?? () from /usr/lib/libsasl.so.1
> #25 0xd19f6ecc in ?? ()
> #26 0x00000128 in ?? ()
> #27 0x5f676572 in ?? ()
> #28 0xd19f3bcf in ?? ()
> #29 0xd1bc27e8 in ?? ()
> #30 0x00000000 in ?? ()
> #31 0xd19f6ed8 in ?? ()
> #32 0x00000000 in ?? ()
> #33 0x00000000 in ?? ()
> #34 0x00000000 in ?? ()
> #35 0x0000013a in ?? ()
> #36 0x0000002a in ?? ()
> #37 0x00000003 in ?? ()
> #38 0x00000019 in ?? ()
> #39 0x00000000 in ?? ()
> #40 0xd1f5bcf9 in _sasl_global_getopt (context=0x88e3d68,
> plugin_name=0x88d4ab0 "@7\215\b\b,\216\b\200=\215\b\230<\216\b",
> option=0x0,
> result=0x0, len=0x80227dc) at ../lib/common.c:1374
> #41 0xd1f58dce in sasl_client_step (conn=0x88e30c8, serverin=0x0,
> serverinlen=0, prompt_need=0x80227dc, clientout=0x80227c4,
> clientoutlen=0x80227bc) at ../lib/client.c:1088
> #42 0xd1f58c1d in sasl_client_start (conn=0x88e30c8, mechlist=0x808f675
> "GSSAPI", prompt_need=0x80227dc, clientout=0x80227c4,
> clientoutlen=0x80227bc, mech=0x80227d0) at ../lib/client.c:1024
> #43 0xd24a27be in nsldapi_sasl_do_bind (ld=0x88e1e00, dn=0x0,
> mechs=0x808f675 "GSSAPI", flags=1, callback=0x8078278
> <lutil_sasl_interact>,
> defaults=0x88c6940, sctrl=0x0, cctrl=0x0) at
> ../sources/ldap/common/sasl.c:660
> #44 0xd24a3121 in ldap_sasl_interactive_bind_s (ld=0x88e1e00, dn=0x0,
> saslMechanism=0x808f675 "GSSAPI", sctrl=0x0, cctrl=0x0, flags=1,
> callback=0x8078278 <lutil_sasl_interact>, defaults=0x88c6940) at
> ../sources/ldap/common/sasl.c:992
> #45 0x08078400 in tool_sasl_bind (ld=0x88e1e00, binddn=0x0, ssl=0) at
> checkldapgroup.c:1840
> #46 0x08079393 in checkldapgroup (username=0x803b450 "markus at SUSE.HOME",
> userdomain=0x803b457 "SUSE.HOME", group=0x88d3bb8 "USERS_ALLOW",
> groupdomain=0x0, rule=0x88d31b0) at checkldapgroup.c:2595
> #47 0x08074753 in ldapgroupmatch (auth=0x803b21c, rule=0x88d0610) at
> accesscheck.c:155
> #48 0x0806ec4b in rulespermit (s=3, peer=0x803fa00, local=0x803fa10,
> clientauth=0x803fa20, match=0x803cb30, srcauth=0x803b21c, state=0x803a9e4,
> src=0x803b564, dst=0x803b9f8, msg=0x803a490 "", msgsize=256) at
> serverconfig.c:1352
> #49 0x08062e70 in run_request (mother=0x80412a0) at sockd_request.c:827
> #50 0x0805e8c3 in addchild (type=4) at sockd_child.c:427
> #51 0x0805f123 in childcheck (type=4) at sockd_child.c:541
> #52 0x0805da28 in main (argc=143409904, argv=0x8047c64, envp=0x8047c70) at
> sockd.c:371
> (gdb)
>
>
> "Greg Hudson" <ghudson at MIT.EDU> wrote in message
> news:1256220048.23997.307.camel at ray...
>> On Wed, 2009-10-21 at 19:20 -0400, Markus Moeller wrote:
>>> I have an application which creates a cache, stores a ticket and then
>>> destroys the cache, but sometimes I get a SEGV. This is on OpenSolaris
>>> (but
>>> I think the code is the same as the MIT code).
>> [...]
>>> Do I need to check if the cache has credentials before a destroy the
>>> cache
>>> ?
>>
>>>From reading the OpenSolaris and MIT krb5 code for memory ccaches, every
>> entry in the ccache is supposed to have valid credentials; there is no
>> operation which should put the credentials list into a state where one
>> of the entries has ->creds == NULL.
>>
>> Because of optimization, it's hard to tell from your stack trace whether
>> the credentials linked list structure has NULL credentials somehow, or
>> if it's an invalid pointer. Either way, the next question would be what
>> operation caused the credentials structure to get into the invalid
>> state.
>>
>>
>> ________________________________________________
>> Kerberos mailing list Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>
>
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
More information about the Kerberos
mailing list