Re: multi-mechanism gssapi

[Luke Howard <lukeh@PADL.COM>]

>1) My main concern is Linux, which has no RTLD_LOCAL or RTLD_GROUP 
>option in dlopen().  It doesn't matter if I link our mechglue library 
>with "-Bsymbolic -Bgroup --allow-shlib-undefined", the heimdal gssapi 
>library needs to be linked with "-Bsymbolic -Bgroup 
>--allow-shlib-undefined" to stop it from calling into our glue routine 
>when calling, for instance, gss_duplicate_name().  I first noticed 
>these problem when we starting building our mechglue library separately 
>and as a shared library instead of linking it statically into our 
>application.

RTLD_LOCAL is the default in Linux, so this probably isn't related.

>2) After building the heimdal library with the above options, I am 
>running into a different problem when calling gss_release_oid_set().
>
>The heimdal version of gss_add_oid_set_member() uses realloc() to 
>allocate new array space for an additional element to be added.  The 
>sun/MIT mechglue code (and the MIT K5 library version) assume that each 
>array element pointer is a separately allocated unit.  The glue code 
>for gss_release_oid_set() doesn't know which mechanism this set was 
>allocated by, and therefore attempts to free it itself.  This causes 
>problems because it assumes it needs to separately free each element 
>pointer and the oid space for each element in the set.  When dealing 
>with a set allocated by the heimdal library, the first free frees the 
>entire oid element array and the next one causes a segfault.
>
>From reading the spec, it is not clear that what heimdal is doing is in 
>violation.  But from what I can see, there is no way for a glue routine 
>to know how to handle this correctly.  Is this another Kitten issue?

I believe the Heimdal code is wrong. An application should not expect
gss_release_oid_set() to free memory which it may have allocated itself.


-- Luke

--