living in a multi-mech world
hartmans at MIT.EDU
Tue May 1 12:11:16 EDT 2007
>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:
>>>>> "Sam" == Sam Hartman <hartmans at MIT.EDU> writes:
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> On Mon, Apr 30, 2007 at 12:16:44AM -0500, Nicolas
Nicolas> Williams wrote:
>>>> Pseudo-mechs shouldn't get direct access to other mechs --
>>>> they should always re-enter the mechglue (recursion ends
>>>> because the various input parameters refer to other
>>>> mechanisms -- as long as the pseudo-mechanism itself is not
>>>> infinitely recursive).
>>>> Re-entering the mechglue from pseudo-mechanisms should add
>>>> some overhead (extra frames on the stack), but not data
Nicolas> Although, provided
Nicolas> gss_get/set_name/cred/context_mech_specific() functions
Nicolas> and a gss_dlopen() then it would be reasonable for
Nicolas> pseudo-mechs to invoke the mechanisms directly. And that
Nicolas> would save a bit of overhead.
Nicolas> _______________________________________________ krbdev
Nicolas> mailing list krbdev at mit.edu
Sam> I think your first statement was more correct. While you
Sam> might make bypassing the mechglue work, it seems like it adds
Sam> a lot of complexity.
Tom> I think it's reasonable for someone to want to have a SPNEGO
Tom> mechanism support only the krb5 mech, for example, so the
Tom> SPNEGO mech could load the krb5 mech and dlsym() the GSS-API
Tom> entry points.
I think this is overly complex.
You can specify a specific oid into the mechglue.
More information about the krbdev