credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

Simo simo at samba.org
Mon Mar 6 15:51:50 UTC 2017


On Mon, 2017-03-06 at 16:32 +0100, Stefan Metzmacher wrote:
> Am 06.03.2017 um 16:28 schrieb Simo:
> > On Mon, 2017-03-06 at 15:19 +0100, Stefan Metzmacher wrote:
> > > Hi Simo,
> > > 
> > > > > Yes, and that's exactly what I want. We should do such things
> > > > > explicit
> > > > > in order to avoid unexpected magic depending on the used
> > > > > kerberos
> > > > > library.
> > > > 
> > > > Can you explain what magic you refer to ?
> > > > What's your goal here ? Keep in mind that in MIT kerberos
> > > > gss_krb5_import_cred() is implemented by calling the
> > > > acquire_cred
> > > > paths
> > > > internally anyway, so the solution for any "magic" is likely
> > > > the
> > > > same
> > > > in either case.
> > > 
> > > See https://bugzilla.samba.org/show_bug.cgi?id=12480, we need to
> > > pass an explicit krb5_ccache in order to avoid the ccselect
> > > magic, which is a security risk in our code. Therefore we need
> > > to call krb5_cc_resolve() ourself. As we don't want the
> > > library to choose any random ccache! Even if we want to use
> > > the default cache for one cli_credential struct, it doesn't
> > > mean we will only ever have one cli_credential in the current
> > > process.
> > 
> > For memory ccaches this should not be a problem with
> > gss_acquire_cred_from() as you would pass a store element like:
> > {
> >     .key = "ccache",
> >     .value = "MEMORY:cliconnect",
> > }
> > therefore selecting a specific ccache to use.
> 
> I know, but we also need this for the default cache
> and as far as I know krb5_cc_default_name() is the function
> to get the default name.

Sorry metze, but I am not sure I follow you,
if you pass no "ccache" kv  pair, then the behavior of
gss_acquire_cred_from() will be the same as passing in explicitly
krb5_cc_default_name() so I am not sure why you would want to do that ?

Simo.



More information about the samba-technical mailing list