[krbdev.mit.edu #2722] Outstanding allocation of krb5_copy_principal() after callking krb5_get_init_creds_password

[schommer@gmail.com via RT]

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 at krbdev.mit.edu> wrote:
> >>>>> "D" == Public Submitter via RT <rt-comment at 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
> 
>