credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

[Stefan Metzmacher]

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.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170303/5a5274cf/signature.sig>