Ticket History #7851: keyring ccache cannot store creds with same server principal

# Fri Jan 24 08:55:01 2014 Sumit Bose <sbose@redhat.com> - Ticket created

Date:	Fri, 24 Jan 2014 11:11:11 +0100
From:	Sumit Bose <sbose@redhat.com>
To:	krb5-bugs@mit.edu
Subject:	Change in behaviour in the kernel keyring ccache

Download (untitled) / with headers
text/plain 4.7KiB

Hi,

I came across the following while testing my S4U2Self patches. If I use kvno to
get ticket for multiple other users the FILE credential cache will store all
ticket while the KEYRING will only store the last S2U2Self ticket. But all the
cross realm TGT are kept as can be seen by the last call. Ordinary service
tickets are kept as well.

I haven't looked at the code but I guess the tickets are replaced because the
service principal is always the same and the client principal is not check.

bye,
Sumit

[root@vm-215 ~]# export KRB5CCNAME=FILE:/tmp/bla
[root@vm-215 ~]# kdestroy -A
[root@vm-215 ~]# klist -A
[root@vm-215 ~]# kinit -k 'VM-215$@DOM1.FOO'
[root@vm-215 ~]# kvno -U 'Administrator@DOM1.FOO' 'VM-215$@DOM1.FOO'
VM-215$@DOM1.FOO: kvno = 4
[root@vm-215 ~]# kvno -U 'Administrator@DOM2.BAR' 'VM-215$@DOM1.FOO'
VM-215$@DOM1.FOO: kvno = 4
[root@vm-215 ~]# kvno -U 'Administrator@SUBDOM.SUB' 'VM-215$@DOM1.FOO'
VM-215$@DOM1.FOO: kvno = 4
[root@vm-215 ~]# klist -A
Ticket cache: FILE:/tmp/bla
Default principal: VM-215$@DOM1.FOO

Valid starting Expires Service principal
23.01.2014 17:16:15 24.01.2014 03:16:15 krbtgt/DOM1.FOO@DOM1.FOO
renew until 30.01.2014 17:16:15
23.01.2014 17:16:23 24.01.2014 03:16:15 VM-215$@DOM1.FOO
for client Administrator\@DOM1.FOO@DOM1.FOO, renew until 30.01.2014 17:16:15
23.01.2014 17:16:26 24.01.2014 03:16:15 krbtgt/DOM2.BAR@DOM1.FOO
renew until 30.01.2014 17:16:15
23.01.2014 17:16:26 24.01.2014 03:16:15 VM-215$@DOM1.FOO
for client Administrator\@DOM2.BAR@DOM2.BAR, renew until 30.01.2014 17:16:15
23.01.2014 17:16:30 24.01.2014 03:16:15 krbtgt/DOM2.BAR@DOM1.FOO
renew until 30.01.2014 17:16:15
23.01.2014 17:16:29 24.01.2014 03:16:15 krbtgt/SUBDOM.SUB@DOM1.FOO
renew until 30.01.2014 17:16:15
23.01.2014 17:16:29 24.01.2014 03:16:15 krbtgt/SUBDOM.SUB@DOM2.BAR
renew until 30.01.2014 17:16:15
23.01.2014 17:16:30 24.01.2014 03:16:15 VM-215$@DOM1.FOO
for client Administrator\@SUBDOM.SUB@SUBDOM.SUB, renew until 30.01.2014 17:16:15
[root@vm-215 ~]# unset KRB5CCNAME
[root@vm-215 ~]# kdestroy -A
[root@vm-215 ~]# klist -A
[root@vm-215 ~]# kinit -k 'VM-215$@DOM1.FOO'
[root@vm-215 ~]# kvno -U 'Administrator@DOM1.FOO' 'VM-215$@DOM1.FOO'
VM-215$@DOM1.FOO: kvno = 4
[root@vm-215 ~]# klist -A
Ticket cache: KEYRING:persistent:0:0
Default principal: VM-215$@DOM1.FOO

Valid starting Expires Service principal
23.01.2014 17:21:36 24.01.2014 03:21:31 VM-215$@DOM1.FOO
for client Administrator\@DOM1.FOO@DOM1.FOO, renew until 30.01.2014 17:21:31
23.01.2014 17:21:31 24.01.2014 03:21:31 krbtgt/DOM1.FOO@DOM1.FOO
renew until 30.01.2014 17:21:31
[root@vm-215 ~]# kvno -U 'Administrator@DOM2.BAR' 'VM-215$@DOM1.FOO'
VM-215$@DOM1.FOO: kvno = 4
[root@vm-215 ~]# klist -A
Ticket cache: KEYRING:persistent:0:0
Default principal: VM-215$@DOM1.FOO

Valid starting Expires Service principal
23.01.2014 17:21:45 24.01.2014 03:21:31 krbtgt/DOM2.BAR@DOM1.FOO
renew until 30.01.2014 17:21:31
23.01.2014 17:21:45 24.01.2014 03:21:31 VM-215$@DOM1.FOO
for client Administrator\@DOM2.BAR@DOM2.BAR, renew until 30.01.2014 17:21:31
23.01.2014 17:21:31 24.01.2014 03:21:31 krbtgt/DOM1.FOO@DOM1.FOO
renew until 30.01.2014 17:21:31
[root@vm-215 ~]# kvno -U 'Administrator@SUBDOM.SUB' 'VM-215$@DOM1.FOO'
VM-215$@DOM1.FOO: kvno = 4
[root@vm-215 ~]# klist -A
Ticket cache: KEYRING:persistent:0:0
Default principal: VM-215$@DOM1.FOO

Valid starting Expires Service principal
23.01.2014 17:21:55 24.01.2014 03:21:31 krbtgt/SUBDOM.SUB@DOM2.BAR
renew until 30.01.2014 17:21:31
23.01.2014 17:21:55 24.01.2014 03:21:31 krbtgt/SUBDOM.SUB@DOM1.FOO
renew until 30.01.2014 17:21:31
23.01.2014 17:21:57 24.01.2014 03:21:31 krbtgt/DOM2.BAR@DOM1.FOO
renew until 30.01.2014 17:21:31
23.01.2014 17:21:57 24.01.2014 03:21:31 VM-215$@DOM1.FOO
for client Administrator\@SUBDOM.SUB@SUBDOM.SUB, renew until 30.01.2014 17:21:31
23.01.2014 17:21:31 24.01.2014 03:21:31 krbtgt/DOM1.FOO@DOM1.FOO
renew until 30.01.2014 17:21:31
[root@vm-215 ~]# kvno -U 'Administrator@DOM1.FOO' 'VM-215$@DOM1.FOO'
VM-215$@DOM1.FOO: kvno = 4
[root@vm-215 ~]# klist -A
Ticket cache: KEYRING:persistent:0:0
Default principal: VM-215$@DOM1.FOO

Valid starting Expires Service principal
23.01.2014 17:21:55 24.01.2014 03:21:31 krbtgt/SUBDOM.SUB@DOM2.BAR
renew until 30.01.2014 17:21:31
23.01.2014 17:21:55 24.01.2014 03:21:31 krbtgt/SUBDOM.SUB@DOM1.FOO
renew until 30.01.2014 17:21:31
23.01.2014 17:21:57 24.01.2014 03:21:31 krbtgt/DOM2.BAR@DOM1.FOO
renew until 30.01.2014 17:21:31
23.01.2014 17:23:11 24.01.2014 03:21:31 VM-215$@DOM1.FOO
for client Administrator\@DOM1.FOO@DOM1.FOO, renew until 30.01.2014 17:21:31
23.01.2014 17:21:31 24.01.2014 03:21:31 krbtgt/DOM1.FOO@DOM1.FOO
renew until 30.01.2014 17:21:31

# Fri Jan 24 11:43:40 2014 ghudson@mit.edu (Greg Hudson) - Correspondence added

Download (untitled) / with headers
text/plain 483B

This is an old bug, predating the 1.12 changes.

When we add a cred key to a keyring ccache, we give it a description by
just unparsing creds->server. We don't use the description for
searching, but it does clarify the output of "keyctl show" or similar.
For normal usage, this works fine, but in any kind of exotic usage it
results in credentials overwriting each other when they only match on the
server name and not other factors such as client name or requested
authdata.

# Fri Jan 24 17:00:21 2014 ghudson@mit.edu (Greg Hudson) - Subject changed from 'Change in behaviour in the kernel keyring ccache' to 'keyring ccache cannot store creds with same server principal'