credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

Alexander Bokovoy ab at samba.org
Fri Mar 3 11:56:40 UTC 2017


On pe, 03 maalis 2017, Alexander Bokovoy wrote:
> On pe, 03 maalis 2017, Stefan Metzmacher wrote:
> > Hi Alexander,
> > 
> > >>> Attached patch is needed for upcoming FreeIPA 4.5 release to allow use
> > >>> of Samba Python bindings in a privile separation mode provided by
> > >>> GSS-proxy (https://pagure.io/gssproxy). FreeIPA bug is here:
> > >>> https://pagure.io/freeipa/issue/6671, Samba bug is
> > >>> https://bugzilla.samba.org/show_bug.cgi?id=12611
> > >>>
> > >>> Please see more details in the commit message.
> > >>
> > >> Please have a look at
> > >> https://bugzilla.samba.org/show_bug.cgi?id=12480
> > >> for the reasons why we can't use gss_acquire_cred().
> > > Sorry Metze, but you are wrong in this particular case.
> > > 
> > > We are using gss_acquire_cred() in a lot of other places -- source3 code
> > > uses GENSEC GSE module on server side through auth_generic_prepare()
> > > which priorities GENSEC GSE. 
> > 
> > No we only use gss_acquire_cred() as a fallback in gse_init_server()
> > when gss_krb5_import_cred() has a bug importing a keytab.
> > 
> > Are you looking at an older relase? that doesn't have the #12480
> > patches?
> No, there is also gss_acquire_cred() in master for source3/libads/sasl.c
> but that is only used if gss_krb5_import_cred() is not defined.
> 
> For 4.5 I'd need to make sure #12480 is patched too.
>  
> > > However, cli_credentials_get_client_gss_creds() is only called in two
> > > places:
> > > 
> > > - gensec_gssapi_client_creds() in source4/auth/gensec/gensec_gssapi.c
> > >   where it is called with default credentials cache. This is client side
> > >   use of GENSEC with GSSAPI and never is called inside winbindd where it
> > >   could stumble on MEMORY: ccaches.
> > 
> > Will operate on cli_credentials_get_client_gss_creds() in almost all cases
> > where we use kerberos, e.g. when the user didn't 'kinit' before
> > and passed a password.
> Nope. It only is used when GENSEC GSSAPI is used. We have separate
> GENSEC Kerberos module that is using other codepaths and provides
> support for the same OIDs. Both don't work with gssproxy due to this
> bug.
> 
> > 
> > See my other mail for the solution we can aim for.
> I did reply to it already. We have two places where we want to use
> non-default ccache:
> 
> source3/libads/sasl.c:  maj = gss_krb5_import_cred(&min, kccache, NULL, NULL, cred);
> 
> source3/librpc/crypto/gse.c:    gss_maj = gss_krb5_import_cred(&gss_min,
> source3/librpc/crypto/gse.c-                                   gse_ctx->ccache,
> 
> 
> Other four are using default ccache. Changing to gss_acquire_cred_from()
> would mean we have to obtain default ccache name first and supply it as
> part of a cred store spec. I have code for that, but I was under
> impression you didn't like using gss_acquire_cred_from() at all.
> 
> If you are OK for gss_acquire_cred_from(), I'll do a wrapper.
Actually, Andreas already has the code for the same path in
cli credentials_krb5.c that does support gss_acquire_cred_from().
https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/master-cli_creds

-- 
/ Alexander Bokovoy



More information about the samba-technical mailing list