credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

[Simo]

On Fri, 2017-03-03 at 13:42 +0200, 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_ct
> x->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.

NO you do not *have* to acquire cred when using
gss_acquire_cred_from(), if you want default cred you can just pass a
cred_store with no "ccache" defined or an empty cred_store.
Empty cred_store is exactly equivalent to gss_acquire_cred().

> If you are OK for gss_acquire_cred_from(), I'll do a wrapper.

I think the wrapper for all of them, at this point will be cleaner and
will properly handle all cases.

Simo.