RE: krb5 mechanism OID; Was: Re: FW: memory leak in some Kerberos APIs?

[Kent_Wu@trendmicro.com]

Hi, Buck:

	Thx for the info, yes, once I used GSS_KRB5_MECHANISM then it works. The GSS-API comes with both Solaris 8 and MIT package don't define this so I overlooked it.

	And indeed Heimdal doesn't have the same memory leak problem as MIT does while getting the TGT,  This did make me sleep better last night. However I just found out today that Heimdal has the memory leaking problem in gss_init_sec_context() which I use to really do the Kerberos authentication after getting TGT. The same piece of code is memory leak free when I linked with SUN GSS library and was leaking 8 bytes when linked with MIT's. Of course in Heimdal I passed GSS_KRB5_MECHANISM specificly so I didn't bother to create the gss_OID and release it afterwards, this is also the only difference I made to this piece of code while integrating with Heimdal. The following is the detailed leaking report from SUN workshop, one chunk of leak is actually fairly large, i.e, 948 bytes.

	I looked at the source code which also utilized gss_init_sec_context() in heimdal and I think pretty much I've freed all the resources I should have. Did I miss something here due to that GSS_KRB5_MECHANISM issue or is this a known issue? One way I can think of to resolve this is to replace gss_init_sec_context() with Kerberos API's to do the job, however I think it's probably fairly time-consuming and might end up the same issue as well if the underlying API's still leak.

Thx a lot.

Kent 

/************************************************************/

Actual leaks report    (actual leaks:        28  total size:    1395 bytes)
 Total  Num of  Leaked      Allocation call stack
 Size   Blocks  Block
                Address
======  ====== ==========  =======================================
   948       1    0x91be8   _krb5_extract_ticket<-get_cred_kdc_usage<-
get_cred_kdc<-get_cred_kdc_la<-get_cred_from_kdc_flags<-
krb5_get_credentials_with_flags<-krb5_get_credentials<-init_auth
    86       5      -       strdup<-copy_general_string
    72       1    0x2cf18   calloc<-get_cred_from_kdc_flags<-
krb5_get_credentials_with_flags<-krb5_get_credentials<-init_auth<-
gss_init_sec_context<-main
    48       3      -       get_addr<-getaddrinfo
    44       1    0x35a08   krb5_build_authenticator<-init_auth<-
gss_init_sec_context<-main
    40       2      -       strdup<-principalname2krb5_principal
    24       1    0x31a60   gssapi_krb5_create_8003_checksum<-init_auth<-
gss_init_sec_context<-main
    17       1    0x2ce48   strdup<-fcc_resolve<-allocate_ccache<-
krb5_cc_resolve<-krb5_cc_default<-init_auth<-gss_init_sec_context<-main
    16       1    0x37b58   principalname2krb5_principal<-_krb5_extract_ticket
<-get_cred_kdc_usage<-get_cred_kdc<-get_cred_kdc_la<-get_cred_from_kdc_flags<-
krb5_get_credentials_with_flags<-krb5_get_credentials
    16       1    0x37bd0   principalname2krb5_principal<-_krb5_extract_ticket
<-get_cred_kdc_usage<-get_cred_kdc<-get_cred_kdc_la<-get_cred_from_kdc_flags<-
krb5_get_credentials_with_flags<-krb5_get_credentials
    12       1    0x2bfc0   allocate_ccache<-krb5_cc_resolve<-krb5_cc_default
<-init_auth<-gss_init_sec_context<-main
    12       2      -       copy_PrincipalName<-principalname2krb5_principal
    12       1    0x37c20   krb5_copy_keyblock<-copy_key<-
krb5_auth_con_getlocalsubkey<-krb5_build_authenticator<-init_auth<-
gss_init_sec_context<-main
    12       1    0x321c0   calloc<-krb5_copy_addresses<-_krb5_extract_ticket
<-get_cred_kdc_usage<-get_cred_kdc<-get_cred_kdc_la<-get_cred_from_kdc_flags<-
krb5_get_credentials_with_flags
     8       1    0x2c5a8   copy_octet_string<-copy_EncryptionKey<-
krb5_copy_keyblock_contents<-krb5_copy_keyblock<-copy_key<-
krb5_auth_con_getlocalsubkey<-krb5_build_authenticator<-init_auth
     8       1    0x371d8   krb5_data_alloc<-krb5_data_copy<-
_krb5_extract_ticket<-get_cred_kdc_usage<-get_cred_kdc<-get_cred_kdc_la<-
get_cred_from_kdc_flags<-krb5_get_credentials_with_flags
     8       1    0x2c5c8   fcc_resolve<-allocate_ccache<-krb5_cc_resolve<-
krb5_cc_default<-init_auth<-gss_init_sec_context<-main
     4       1    0x34a00   copy_octet_string<-copy_HostAddress<-
krb5_copy_address<-krb5_copy_addresses<-_krb5_extract_ticket<-
get_cred_kdc_usage<-get_cred_kdc<-get_cred_kdc_la
     4       1    0x37298   calloc<-krb5_build_authenticator<-init_auth<-
gss_init_sec_context<-main
     4       1    0x34b00   copy_PrincipalName<-krb5_build_authenticator<-
init_auth<-gss_init_sec_context<-main




-----Original Message-----
From: Buck Huppmann [mailto:buckh@pobox.com]
Sent: Thursday, June 12, 2003 4:30 AM
To: Kent Wu (RD-US)
Cc: heimdal-discuss@sics.se
Subject: krb5 mechanism OID; Was: Re: FW: memory leak in some Kerberos
APIs?


On Wed, Jun 11, 2003 at 06:59:15PM -0700, Kent_Wu@trendmicro.com wrote:
> Hi,
> 
>	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.

can't you just pass it GSS_KRB5_MECHANISM?

$ grep GSS_KRB5_MECHANISM /usr/include/gssapi.h 
extern gss_OID GSS_KRB5_MECHANISM;
#define gss_mech_krb5 GSS_KRB5_MECHANISM
$ nm --defined-only /usr/lib/libgssapi.a | grep GSS_KRB5_MECHANISM
00000074 D GSS_KRB5_MECHANISM