Fixes for S3 DCE/RPC GSSAPI with Heimdal

Luke Howard lukeh at
Mon Apr 18 10:45:43 MDT 2011

> I've asked you below about this history of PAC functions in MIT.  Did
> MIT kerberos ever allow PAC access without doing the crypto, authtime
> and principal checking?

We can discuss this in person at SambaXP if you like. There's probably a better solution, although we're stuck with MIT and Heimdal as shipped for now.

>> The MIT API seem to require you to free it.
>> MIT's gss_release_oid() internally recognizes if the OID is one of its
>> constants and in that case it just returns without freeing.
> Wow!

I believe the MIT behaviour is correct, though. I ran into this problem the other day with the GS2 SASL plugin. I just made it a special case for Heimdal, not so nice.

> If I can show that the MIT API also returns a constant but allows
> (rather than requires) gss_release_oid() to avoid a segfault, would you
> be willing to avoid this call?

The only problem with this is that some mechanisms may return dynamically allocated OIDs. e.g. in the GSS EAP mechanism, we don't know the complete set of mechanisms at compile time (think dynamic sub-mechanisms). For the concrete mechanisms we know about, we can intern the OIDs (so they are constant), but otherwise we may return allocated OIDs.

> Luke:  Do you know if there are version of MIT Kerberos with PAC access
> functions that don't do the PAC checks?

See other mail. I guess a nice fix is to add support for gss_get_name_attribute() in the Heimdal krb5 mech. (Support in the mechglue is already there, I added it.) This should be fairly trivial, even if we can't use the MIT code.

-- Luke

More information about the samba-technical mailing list