[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multi-mechanism gssapi
>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
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.