new 1.10 krb5_init_context_profile

[Chris Hecker]

Okay, it looks like you're supposed to supply a vtable to do this, but
man, that's a ton of duplicate code to do all the relation stuff.  In
the meantime until Greg et al. respond, I kept my profile_init_emtpy()
and added a KRB5_INIT_CONTEXT_NO_COPY_PROFILE flag to
krb5_init_context_profile(), and I just stuff ctx->profile = profile if
it's set instead of calling profile_copy in krb5_os_init_context() and
I'm back in business.

I'd obviously rather not have to modify the API, but I really don't want
to write and test a bunch of code that could just be using the current
profile relation code without modification...either by just using the
passed in profile without copying it, or by having a flag on the profile
that didn't always try to treat it as a file.

Thoughts?

Chris


On 2012/02/14 14:31, Chris Hecker wrote:
> 
> You may recall a while back I hacked 1.9.x to accept an in-memory
> dynamic profile, and I'm now upgrading to 1.10, and trying to make the
> official krb5_init_context_profile work, but I'm having some issues.  I
> figured I'd send this mail out while I spelunk further to parallel
> process...and get an email in the archives on the topic.
> 
> Basically, I added a profile_init_empty() that would make an in-memory
> profile with all the necessary bits initialized and the right flags set
> so nothing was written to a file.  I named the first_file prf_data
> "dynamic" since it needed a name.  If I just use this code, the copy
> inside krb5_init_context_profile tries to open a file named "dynamic"
> which obviously doesn't work.
> 
> If I try to use profile_init_flags with a 0 file, the "emtpy" profile
> returned can't be used by any of the profile_add_relation functions
> because they crash because there's no first_file in the structure.
> 
> Is there an example of how to do an in-memory profile correctly?
> 
> Thanks,
> Chris