Proposal: krb5_get_init_creds_opt_set_change_password_prompt

[Jeffrey Altman]

Kevin Coffman wrote:
>> krb5_get_init_creds_opt_init() must not be called after
>> krb5_get_init_creds_opt_init_new().
> 
> Are you implying that we should be able to enforce this, or only that
> it should be a stated restriction?  (I'm not clear how we can enforce
> it.)

It must be documented as don't do this or else.

>> krb5_get_init_creds_opt_free() would only free the structure if the
>> KRB5_GET_INIT_CREDS_OPT_RESERVED flag bit is set.
> 
> Might this be unsafe if an application mallocs its own init_creds_opt
> structure (the current normal situation) and then calls
> krb5_get_init_creds_opt_free() w/o calling init() or init_new()?  (The
> RESERVED flag may "set" because of random garbage.)

If the developer doesn't either memset() their allocation or call
krb5_get_init_creds_opt_init() then they are already risking danger
because all of the rest of the fields are going to be random.  I'm
not sure I care about this case.

If they call krb5_get_init_creds_opt_init() on the structure returned
by krb5_get_init_creds_opt_alloc() (the Heimdal name) then they will
create a memory leak.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20061117/9f7b6c81/attachment.bin