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