credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

[Stefan Metzmacher]

Am 06.03.2017 um 16:51 schrieb Simo:
> On Mon, 2017-03-06 at 16:32 +0100, Stefan Metzmacher wrote:
>> 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.
> 
> Sorry metze, but I am not sure I follow you,
> if you pass no "ccache" kv  pair, then the behavior of
> gss_acquire_cred_from() will be the same as passing in explicitly
> krb5_cc_default_name() so I am not sure why you would want to do that ?

It should be the same, but it's not. See my other mail for the details.
This difference is exactly the problem we need to work around.

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/b9b6d83f/signature.sig>