[20354] in Kerberos_V5_Development
Re: Use of kdc_send_hook with gss_init_sec_context
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Fri Feb 4 15:37:55 2022
MIME-Version: 1.0
In-Reply-To: <10f3f86c-ccc1-e122-4abb-1795faaa0647@mit.edu>
From: Isaac Boukris <iboukris@gmail.com>
Date: Fri, 4 Feb 2022 22:36:39 +0200
Message-ID: <CAC-fF8SU5GxqT1SBseCWYPCUfGTAJwhgLzjBfZT_HFDFx99xEw@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "krbdev@mit.edu Dev List" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, Feb 4, 2022 at 8:34 PM Greg Hudson <ghudson@mit.edu> wrote:
>
> On 2/4/22 11:57 AM, Isaac Boukris wrote:
> >>> Is there a way to use 'kdc_send_hook' with 'gss_init_sec_context'?
> >>> If there isn't, can we add something like 'gsskrb5_set_krb5_context'?
>
> I've floated this idea before, as a way to bridge libkrb5 functionality
> (such as krb5_init_context_profile()) and GSS.
>
> Nico dislikes the idea because he doesn't like anything that encourages
> mechanism-specific code in GSS applications. He tends to favor name
> attributes as the extension point when possible.
>
> Sam has raised a more specific objection: if the context set by
> gsskrb5_set_krb5_context() is per-thread (which is the easiest way to
> get around contexts not being thread-safe), then it could be a source of
> subtle bugs if someone creates a GSS object in one thread and gets
> different behavior when they use it in another thread.
Also typically the krb5 specifics are set via krb5.conf, so maybe we
can do the same for kdc_send_hook, by specifying an so file the the
conf.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
