Proposal: krb5_get_init_creds_opt_set_change_password_prompt

[Kevin Coffman]

On 11/16/06, Jeffrey Altman <jaltman at secure-endpoints.com> wrote:
> Kevin Coffman wrote:
> > On 11/15/06, Sam Hartman <hartmans at mit.edu> wrote:
> >> Jeff, the get_init_creds_options structure is exposed in the ABI.
> >>
> >> We do need a way of extending that structure for preauth plugin
> >> options, and if we can get it for 1.6 we want it.  But it needs to be
> >> more complicated than what you provide.
> >>
> >> My best guess is that we provide a new allocator function and a way of
> >> detecting wether the caller has used this new allocate function or
> >> not.
> >>
> >> I'd like to find a simpler solution than that.
> >>
> >> Other than the ABI problem, your proposal looks reasonable.
> >>
> >> --Sam
> >
> > I've been thinking about this as related to pkinit, but haven't
> > followed it all the way through.  I'm looking for confirmation whether
> > this idea has potential.
> >
> > Could we do like Heimdal has done and add an "opt_private" pointer to
> > the krb5_get_init_creds_opt structure. krb5_get_init_creds_opt_init()
> > would set a new flag which indicates that the opt_private pointer is
> > invalid.  We can reset that flag when a (new) call is made that causes
> > the allocation of the opt_private structure.  (I'm unclear whether we
> > need a refcount in this opt_private structure as Heimdal has.)
> >
> > K.C.
>
> As Sam pointed out, we have an initial problem in that the existing
> get_init_creds_options structure is publicly defined.  Therefore, we
> can't modify it to add the new opt_private pointer.
>
> Sam has proposed that we define a new extended
> krb5_get_init_creds_options structure that would be allocated by a
> replacement for krb5_get_init_creds_opt_init()
>
>
> krb5_error_code KRB5_CALLCONV
> krb5_get_init_creds_opt_init_new (krb5_get_init_creds_opt **opt);
>
> krb5_error_code KRB5_CALLCONV
> krb5_get_init_creds_opt_free (krb5_get_init_creds_opt *opt);
>
> The krb5_get_init_creds_opt_init_new() call would allocate a
> private structure whose initial fields match those of the public
> krb5_get_init_creds_opt structure.  A special flag value would
> be allocated to indicate that the structure was allocated by
> krb5_get_init_creds_opt_new().
>
> #define KRB5_GET_INIT_CREDS_OPT_RESERVED 0x8000
>
> 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.)

> 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.)

> Once this is done it would be possible to extend the private structure
> with as many fields are required.  The shape of the structure could be
> determined based upon the number and types of pre-auth plugins that have
> been loaded provided that the plug-ins provide a method of querying for
> their requirements.
>
> Jeffrey Altman