credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

[Alexander Bokovoy]

On pe, 03 maalis 2017, Alexander Bokovoy wrote:
> On pe, 03 maalis 2017, Stefan Metzmacher wrote:
> > Am 03.03.2017 um 13:07 schrieb Alexander Bokovoy:
> > > 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().
> > >>>>>
> > >>>>> There needs to be another solution, sorry.
> > >>>>
> > >>>> As gss_acquire_cred_from() seems to be handled by gssproxy,
> > >>>> I guess we need a wrapper in lib/krb5_wrap/gss_samba.[ch]
> > >>>> that uses gss_acquire_cred_from() if available and
> > >>>> gss_krb5_import_cred() otherwise.
> > >>>>
> > >>>> And that wrapper needs to be used everywhere we currently
> > >>>> use gss_krb5_import_cred(). It should also hide the mess
> > >>>> we currently use in gse_init_server() to work arround
> > >>>> the broken gss_krb5_import_cred() server side.
> > >>> That was my initial idea but the problem here is that we deal with it 
> > >>> differently in different contexts. In client context we use GSSAPI creds
> > >>> while in other places we use KRB5 ccache handle.
> > >>>
> > >>> This particular code path is isolated from other use of
> > >>> gss_krb5_import_cred(). And it does not need to specify explicit
> > >>> credential cache because it is running in a client context and expects
> > >>> to use the default ccache.
> > >>
> > >> That's wrong this code path operates on multiple MEMORY caches
> > >> in smbtorture.
> > >>
> > >> gss_acquire_cred() never used again for initiator creds
> > >> and only for acceptor creds as a fallback for a broken
> > >> gss_krb5_import_cred().
> > >>
> > >> So all places should use the wrapper that uses
> > >> gss_acquire_cred_from() if available. It should
> > >> otherwise use gss_krb5_import_cred() with
> > >> a fallback only for the keytab only case
> > >> to gsskrb5_register_acceptor_identity()/gss_acquire_cred().
> > > So, what about Andreas' code from
> > > https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/master-cli_creds
> > > ?
> > 
> > I know I also had some of this in my master3-libsmb-tmp,
> > but skipped it as it was not required yet.
> > 
> > > The only issue I see there is that when gensec_gssapi calls into
> > > cli_credentials_get_client_gss_creds() with NULL ccache, it wants to get
> > > the creds from the default ccache but Andreas' code will try to create a
> > > new MEMORY: ccache. This is wrong for the use case we have with
> > > cli_credentials_get_client_gss_creds() because this ccache is empty and
> > > default one contains actual credentials.
> > 
> > I think I'd preferr to have a wrapper that behaves like
> > gss_krb5_import_cred() on heimdal, just
> > 
> > uint32_t smb_gss_krb5_import_cred(OM_uint32 *minor_status,
> >                      krb5_ccache id,
> >                      krb5_principal keytab_principal,
> >                      krb5_keytab keytab,
> >                      gss_cred_id_t *cred);
> > 
> > And change the callers just to use it without any additional
> > logic change.
> > 
> > That would be much easier to understand.
> ACK. Will do that.
I pushed current patchset to
https://git.samba.org/?p=ab/samba.git/.git;a=shortlog;h=refs/heads/master-gss_acquire_cred_from

I'm running tests right now. Will submit final patch once they pass.


-- 
/ Alexander Bokovoy