credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

[Stefan Metzmacher]

Am 06.03.2017 um 15:43 schrieb Alexander Bokovoy:
> On ma, 06 maalis 2017, 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.
> With gss_acquire_cred_from() we don't need to call krb5_cc_resolve() as
> you can pass information about specific ccache reference in the cred
> store details. That's one of the improvements here.

As far as I understand the code, the keypoint is that
acquire_cred_context() gets an explicit ccache, otherwise
the ccselect logic will be triggered later. That means
krb5_gss_acquire_cred_from() needs an explicit ccache name.
In order to pass it explicit we need to use krb5_cc_default_name()
anyway, so using krb5_cc_resolve() also doesn't make any difference,
but make things more explicit.

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