SEGV in krb5_free_cred_contents on Opensolaris
Markus Moeller
huaraz at moeller.plus.com
Sun Nov 1 14:18:53 EST 2009
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
>
More information about the Kerberos
mailing list