[SSSD] KRB5CCNAME variable broken in second concurrent login shell - bug?

Joschi Brauchle joschi.brauchle at tum.de
Wed Oct 15 21:41:47 UTC 2014


On 10/15/2014 06:31 PM, Joschi Brauchle wrote:
> On 10/15/2014 05:45 PM, Lukas Slebodnik wrote:
>> On (15/10/14 17:00), Joschi Brauchle wrote:
>>> On 10/15/2014 02:58 PM, Lukas Slebodnik wrote:
>>>> On (15/10/14 14:37), Joschi Brauchle wrote:
>>>>> We have a weird problem with the KRB5CCNAME environment variable
>>>>> that seems
>>>>> to be an SSSD bug.
>>>>>
>>>>> Configuration:
>>>>> ------------ /etc/sssd/sssd.conf ------------
>>>>> ...
>>>>> # Set CCache to Kerberos default
>>>>> krb5_ccachedir = /run/user/%U
>>>>> krb5_ccname_template = DIR:%d/krb5cc
>>>>> ...
>>>>> ------------ /etc/sssd/sssd.conf ------------
>>>>>
>>>>> Now, user "ne96soh" logs in to the machine for the FIRST time and
>>>>> does a
>>>>> kerberized ldapsearch:
>>>>> ------------
>>>>> ne96soh at tueilnt-student01:~$ echo $KRB5CCNAME
>>>>> DIR:/run/user/3036404/krb5cc
>>>>> ne96soh at tueilnt-student01:~$ klist
>>>>> Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
>>>>> ...
>>>>> ne96soh at tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
>>>>> ... <succeeds>
>>>>> ------------
>>>>>
>>>>> but then logs into the machine a SECOND concurrent time (i.e.
>>>>> leaving first
>>>>> session open):
>>>>> ------------
>>>>> ne96soh at tueilnt-student01:~$ echo $KRB5CCNAME
>>>>> DIR::/run/user/3036404/krb5cc/tktZoweZq
>>>>> ne96soh at tueilnt-student01:~$ klist
>>>>> Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
>>>>> ...
>>>> Which version of sssd do you use?
>>>> IIRC, We forced to store "DIR:/run/user/3036404/krb5cc/" into our
>>>> internal
>>>> cache.
>>>>
>>>> LS
>>>>
>>>> BTW "DIR::/run/user/3036404/krb5cc/tktZoweZq" is valid ccache
>>>> string. It means
>>>> you use just one ccache from colection.
>>>>
>>>> This version "DIR:/run/user/3036404/krb5cc/" means that any ccache
>>>> which is
>>>> stored in ccache collection (directory "/run/user/3036404/krb5cc/"
>>>> can be used)
>>>> As first ccache would be used primary ccache.
>>>>
>>>> With KRB5CCNAME="DIR:/run/user/3036404/krb5cc/" you can call "klist -l"
>>>> and you will see all ccaches stored in this directory.
>>>
>>>
>>> Sorry for not specifying the SSSD version.
>>> It is 1.9.6 (fairly old, I know).
>>>
>> old but should be stable :-)
>>
>>> So if "DIR::/run/user/3036404/krb5cc/tktZoweZq" is a valid ccache
>>> file, why
>>> does the kerberized ldapsearch fail then?
>>>
>>> I am guessing that ldapsearch just calls some other library (sasl?)
>>> to get
>>> the krb credentials. Hence, somewhere along the chain this
>>> "DIR::/run/user/3036404/krb5cc/tktZoweZq" is not accepted...
>>>
>>
>> Here is an upstream ticket
>> https://fedorahosted.org/sssd/ticket/2002
>>
>> The patch was backported just to the branch sssd-1.10 and never into
>> sssd-1.9
>> https://git.fedorahosted.org/cgit/sssd.git/commit/?id=f65eb572cbc8796fefaad52e36a9a6cea0cf51bd
>>
>>
>> If you want you can patch it yourself.
>>
>> LS
>
> I have ported the patch to 1.9.6. but still get the exact same behavior
> as described in the original email, unfortunately.
>

I have dug up
https://fedorahosted.org/sssd/ticket/1936
which exactly fits my problem description and contains patches to sssd 
 >1.10:

d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
d673bd397f1ed8239b36a5134bcd29914b11ae72
fa3cdcff460d555f4a4905fb0a2d96be564fc599

Unfortunately the last one does not apply successful to sssd 1.9.6, 
which is where my clumsy efforts are reaching their time limitation.

Could these patches be possibly backported to a new/final 1.9.7 version 
for me to test?

Best regards,
Joschi Brauchle

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4917 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20141015/8bb8b6ec/attachment.p7s>


More information about the sssd-devel mailing list