Proposal: krb5_get_init_creds_opt_set_change_password_prompt

[Kevin Coffman]

On 11/17/06, Jeffrey Altman <jaltman at secure-endpoints.com> wrote:
> 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

I'll take a stab at implementing this over the weekend and then you
can shoot holes in it :-)