SEGV in krb5_free_cred_contents on Opensolaris

[Markus Moeller]

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
>