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

[Tom Yu via RT]

>>>>> "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