kwc at citi.umich.edu
Fri Nov 17 11:11:39 EST 2006
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
> #define KRB5_GET_INIT_CREDS_OPT_RESERVED 0x8000
> krb5_get_init_creds_opt_init() must not be called after
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
> 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
More information about the krbdev