credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

[Stefan Metzmacher]

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.

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/20170306/8eb84fad/signature.sig>