Re: multi-mechanism gssapi

[Kevin Coffman <kwc@citi.umich.edu>]

> 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?

Looking at this further, it looks like the heimdal code is returning a
pointer to static storage for the member OID elements rather than a
dynamic copy as specified in rfc2744?