[Patches] avoid krb5_ccache ccselect magic (bug #12480)

[Stefan Metzmacher]

Am 30.12.2016 um 00:02 schrieb Stefan Metzmacher:
> Hi Alexander,
> 
>>> From 69723ac36d31effd5c1949de0ce693d2face7b2c Mon Sep 17 00:00:00 2001
>>> From: Stefan Metzmacher <metze at samba.org>
>>> Date: Thu, 22 Dec 2016 08:49:38 +0100
>>> Subject: [PATCH 3/3] s3:librpc/gse: make use of gss_krb5_import_cred() instead
>>>  of gss_acquire_cred()
>>>
>>> This avoids the usage of the ccselect_realm logic in MIT krb5,
>>> which leads to unpredictable results.
>>>
>>> The problem is the usage of gss_acquire_cred(), that just creates
>>> a credential handle without ccache.
>>>
>>> As result gss_init_sec_context() will trigger a code path
>>> where it use "ccselect" plugins. And the ccselect_realm
>>> module just chooses a random ccache from a global list
>>> where the realm of the provides target principal matches
>>> the realm of the ccache user principal.
>>>
>>> In the winbindd case we're using MEMORY:cliconnect to setup
>>> the smb connection to the DC. For ldap connections we use
>>> MEMORY:winbind_ccache.
>>>
>>> The typical case is that we do the smb connection first.
>>> If we try to create a new ldap connection, while the
>>> credentials in MEMORY:cliconnect are expired,
>>> we'll do the required kinit into MEMORY:winbind_ccache,
>>> but the ccselect_realm module will select MEMORY:cliconnect
>>> and tries to get a service ticket for the ldap server
>>> using the already expired TGT from MEMORY:cliconnect.
>>>
>>> The solution will be to use gss_krb5_import_cred() and explicitly
>>> pass the desired ccache, which avoids the ccselect logic.
>>>
>>> We could also use gss_acquire_cred_from(), but that's only available
>>> in modern MIT krb5 versions, while gss_krb5_import_cred() is available
>>> in heimdal and all supported MIT versions (>=1.9).
>>> As far as I can see both call the same internal function in MIT
>>> (at least for the ccache case).
>>>
>>> BUG: https://bugzilla.samba.org/show_bug.cgi?id=12480
>>>
>>> Signed-off-by: Stefan Metzmacher <metze at samba.org>
>>> Reviewed-by: Andreas Schneider <asn at samba.org>
>>
>> This is because memory credentials cache in MIT Kerberos implements
>> collection traversal API and has no way to toggle the behavior to stick
>> to a single ccache instead of traversing sequentially the whole
>> collection. I guess this was known to core MIT developers since 2005
>> when Tom Yu implemented cursor API in the memory ccache backend but
>> wasn't really realized by external community when MIT Kerberos 1.10
>> officially added support for credentials collection based on the
>> collection traversal API. The documentation (doc/basic/ccache_def.rst) 
>> claims that 
>> =============
>> Credential cache collections are new in release 1.10, with support
>> from the **DIR** and **API** ccache types.  Starting in release 1.12,
>> collections are also supported by the **KEYRING** ccache type.
>> Collections are supported by the **KCM** ccache type in release 1.13.
>> =============
>>
>> So MEMORY ccache type should not be treated as the collection but it
>> is. I guess we have to raise this question to the MIT Kerberos
>> development team and see how can we fix it.
>>
>> API ccache type is a Windows-only thing.
>>
>> Until there is a fix in MIT Kerberos for MEMORY ccache type not being
>> treated as a credentials caches collection, I fear we have to include
>> this patch.
> 
> I guess for some application it might be useful to use all available
> credential caches. If the application runs as one logical user
> which has multiple identities in multiple independed realms.
> And I don't think this should change.

I guess the application needs to explicitly open all individual
ccaches which will together form the global collection.
Is that correct? Or is it possible to specify something like
KRB5CCNAME="FILE:/tmp/user1_realmA.ccache_file;DIR=/tmp/user2_realmB.ccache_dir/"
that magically opens more than one cache at a time?

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