Skip Menu |
 

Subject: Outstanding allocation of krb5_copy_principal() after callking krb5_get_init_creds_password
Cc: hartmans@mit.edu
Download (untitled) / with headers
text/plain 1.1KiB
==20711== 28 bytes in 1 blocks are definitely lost in loss record 8 of 10
==20711== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==20711== by 0x13CA8F: krb5_copy_principal (in /usr/lib/libkrb5.so.3.2)
==20711== by 0x1405B5: (within /usr/lib/libkrb5.so.3.2)
==20711== by 0x1416BB: krb5_get_init_creds (in /usr/lib/libkrb5.so.3.2)
==20711== by 0x142837: krb5_get_init_creds_password (in
/usr/lib/libkrb5.so.3.2)


I call get_init_creds_password:

krb5_get_init_creds_password( ctx,
&m_clientCreds,
clientPrincipal,
(char * )szPassword.c_str(),
NULL, NULL, 0, NULL,
&options ) );

And later I do:
krb5_free_cred_contents( ctx, &m_clientCreds );
and:
krb5_free_principal( ctx, clientPrincipal );

I am using valgrind-2.2.0-1 to find this issue.

After talking with Sam Hartman it seems this is happening mainly to me,
and not in the standard kinit code. I am thinking that some API call's
I've made prior to this one is perhaps setting me up for failure.

I will see if I can hunt it down.
Ok, now I see the problem. I missed an api call that I made...

krb5_get_init_creds_password( ctx, creds, ... );

Then I do a few more API calls, and found this:

krb5_parse_name( ctx, szHostPrincipal, &creds.server );

This over-writes the prior server credentials from creds_password (which
was "krbtgt").

Is this a bug, or user error? If possible, could we avoid this type of
"user error" by freeing the principal that was in creds.server within
the krb5_parse_name()?

So that if you parse_name and store the principal name the API would
check to see if one exists first, and delete it. THEN store the new one?

To avoid the leak what I did was:

krb5_get_init_creds_password( ctx, creds, ... );
krb5_cc_store_cred()
krb5_free_principal( ctx, creds.server );
krb5_parse_name_ ctx, szHostPrincipal, &creds.server );


Just wondering if that request is something that you guys feel would be
a good addition. And if you don't, feel free to call this "functions as
designed"

Thanks,

Ds.
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2722] Outstanding allocation of krb5_copy_principal() after callking krb5_get_init_creds_password
From: Tom Yu <tlyu@mit.edu>
Date: Fri, 24 Sep 2004 12:16:59 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
Show quoted text
>>>>> "D" == Public Submitter via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
D> Ok, now I see the problem. I missed an api call that I made...
D> krb5_get_init_creds_password( ctx, creds, ... );

Show quoted text
D> Then I do a few more API calls, and found this:

Show quoted text
D> krb5_parse_name( ctx, szHostPrincipal, &creds.server );

Show quoted text
D> This over-writes the prior server credentials from creds_password (which
D> was "krbtgt").

Show quoted text
D> Is this a bug, or user error? If possible, could we avoid this type of
D> "user error" by freeing the principal that was in creds.server within
D> the krb5_parse_name()?

I think we would classify this as a programmer error. The problem
with having krb5_parse_name() free the target princpial if it's
non-null is that a caller passing in an uninitialized pointer could
cause krb5_parse_name() to free unallocated memory.

Show quoted text
D> To avoid the leak what I did was:

Show quoted text
D> krb5_get_init_creds_password( ctx, creds, ... );
D> krb5_cc_store_cred()
D> krb5_free_principal( ctx, creds.server );
D> krb5_parse_name_ ctx, szHostPrincipal, &creds.server );

It's probably a bad idea to modify the creds returned by
get_init_creds().

---Tom
Date: Fri, 24 Sep 2004 13:07:55 -0400
From: Derrick Schommer <schommer@gmail.com>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2722] Outstanding allocation of krb5_copy_principal() after callking krb5_get_init_creds_password
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.5KiB
So I would have to generate a new creds structure, obtain my client
principal data from the cache after I just stored it from the
init_creds_password(), and then set the server principal? Just seems
like a wasted effort when I already have a creds structure with the
client principal in it...


On Fri, 24 Sep 2004 12:17:02 -0400 (EDT), Tom Yu via RT
<rt-comment@krbdev.mit.edu> wrote:
Show quoted text
> >>>>> "D" == Public Submitter via RT <rt-comment@krbdev.mit.edu> writes:
>
> D> Ok, now I see the problem. I missed an api call that I made...
> D> krb5_get_init_creds_password( ctx, creds, ... );
>
> D> Then I do a few more API calls, and found this:
>
> D> krb5_parse_name( ctx, szHostPrincipal, &creds.server );
>
> D> This over-writes the prior server credentials from creds_password (which
> D> was "krbtgt").
>
> D> Is this a bug, or user error? If possible, could we avoid this type of
> D> "user error" by freeing the principal that was in creds.server within
> D> the krb5_parse_name()?
>
> I think we would classify this as a programmer error. The problem
> with having krb5_parse_name() free the target princpial if it's
> non-null is that a caller passing in an uninitialized pointer could
> cause krb5_parse_name() to free unallocated memory.
>
> D> To avoid the leak what I did was:
>
> D> krb5_get_init_creds_password( ctx, creds, ... );
> D> krb5_cc_store_cred()
> D> krb5_free_principal( ctx, creds.server );
> D> krb5_parse_name_ ctx, szHostPrincipal, &creds.server );
>
> It's probably a bad idea to modify the creds returned by
> get_init_creds().
>
> ---Tom
>
>
Date: Fri, 24 Sep 2004 13:07:55 -0400
From: Derrick Schommer <schommer@gmail.com>
To: rt-comment@krbdev.mit.edu, rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #2722] Outstanding allocation of krb5_copy_principal() after callking krb5_get_init_creds_password
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.5KiB
So I would have to generate a new creds structure, obtain my client
principal data from the cache after I just stored it from the
init_creds_password(), and then set the server principal? Just seems
like a wasted effort when I already have a creds structure with the
client principal in it...


On Fri, 24 Sep 2004 12:17:02 -0400 (EDT), Tom Yu via RT
<rt-comment@krbdev.mit.edu> wrote:
Show quoted text
> >>>>> "D" == Public Submitter via RT <rt-comment@krbdev.mit.edu> writes:
>
> D> Ok, now I see the problem. I missed an api call that I made...
> D> krb5_get_init_creds_password( ctx, creds, ... );
>
> D> Then I do a few more API calls, and found this:
>
> D> krb5_parse_name( ctx, szHostPrincipal, &creds.server );
>
> D> This over-writes the prior server credentials from creds_password (which
> D> was "krbtgt").
>
> D> Is this a bug, or user error? If possible, could we avoid this type of
> D> "user error" by freeing the principal that was in creds.server within
> D> the krb5_parse_name()?
>
> I think we would classify this as a programmer error. The problem
> with having krb5_parse_name() free the target princpial if it's
> non-null is that a caller passing in an uninitialized pointer could
> cause krb5_parse_name() to free unallocated memory.
>
> D> To avoid the leak what I did was:
>
> D> krb5_get_init_creds_password( ctx, creds, ... );
> D> krb5_cc_store_cred()
> D> krb5_free_principal( ctx, creds.server );
> D> krb5_parse_name_ ctx, szHostPrincipal, &creds.server );
>
> It's probably a bad idea to modify the creds returned by
> get_init_creds().
>
> ---Tom
>
>
After understanding what was going on, it makes sense that this was user
error and not an API issue. Not worth keeping up as an outstanding issue...