[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FW: memory leak in some Kerberos APIs?


	Once I tried to use the heimdal library, one conflict I got is actually from GSS-API side. In my program, after getting the TGT, I will use GSS-API to do the kerberos authentication, while calling gss_init_sec_context() I explicitly passed Kerberos mechanism instead of GSS_C_NO_OID in. The mechanism OID for Kerberos is "1.2.840.113554.1.2.2", of course before passing this argument to gss_init_sec_context() I need to transfer it into a gss_OID object.

	This approach works fine in MIT package however here I found there is no definition for:
in heimdal which I used to convert the "1.2.840.113554.1.2.2" to an OID object then released it afterwards. Does heimdal provide other API's to do the same job? Or if I can just pass GSS_C_NO_OID to make it work, how should I configure my Solaris 8 machine to make the default mechanism the Kerberos one?



-----Original Message-----
From: Kent Wu (RD-US) 
Sent: Monday, June 09, 2003 2:29 PM
To: joda@pdc.kth.se
Cc: heimdal-discuss@sics.se
Subject: RE: FW: memory leak in some Kerberos APIs?

Hi, Johan:

	It seems it has been on the to-do list for a while though. :)

	What we tried to achieve is to verify user's credentail if we turn proxy authorization on (407 reutrn code) in http traffic. The problem with the krb5_context not being thread-safe is that in the multi-thread env, we need to implement a sync lock around the authentication code to guarantee exclusion, which might slow down the performance that is crucial in http traffic.

	However if that's the status so far, I think we can live with it. BTW, I still can't get my memory leak problem resolved in MIT library, I think I'll try the heimdal instead.

Thx a lot.


-----Original Message-----
From: Johan Danielsson [mailto:joda@pdc.kth.se]
Sent: Saturday, June 07, 2003 6:32 AM
To: Kent Wu (RD-US)
Cc: heimdal-discuss@sics.se
Subject: Re: FW: memory leak in some Kerberos APIs?

<Kent_Wu@trendmicro.com> writes:

> BTW, according to the material I read so far the Kerberos library is
> not really thread-safe, do you guys have plans to make it
> thread-safe?

It's on the todo-list. I think there is talk about this in the MIT
camp also.

Is this something you need, or does it just sound like a good idea? Do
you have anything specific you want to do?