behaviour of kinit with respect to KRB5CCNAME

[Harald Barth]

I have just installed a mint 17.1 and with that I got a
1.6~git20131207+dfsg-1ubuntu1 heimdal.

Now the kinit I got with that behaves very strange:

In spite setting KRB5CCNAME to FILE:/tmp/xxx, kinit still updates
FILE:/tmp/krb5cc_MYUID when the principal matches what already is in
FILE:/tmp/krb5cc_MYUID, but makes a new credential cache in
FILE:/tmp/xxx when the principal does not match.

This is not the expected behaviour and the manpage for kinit says:

KRB5CCNAME
Specifies the default credentials cache.

without mentioning any exceptions.

As well I expect kinit and klist to work on the same credential
cache when I set the default cache with KRB5CCNAME and have not
taken any other steps.

Can someone point me to the patch which has introduced this nonsense?

Is this bug known/fixed in 1.6 tip and/or HEAD?

I guess that this behaviour is somehow related to kswitch.

Is there some documentation which shows how kswitch and KRB5CCNAME
interact?

Is there some documentation how I can specify several caches of type
FILE to kswitch to choose from?

As you might guess, my first meet with this new credential cache
switching functinality is not a happy one and cost me some time
searching around to where the heck my credentials were gone.

KRB5CCNAME has for years specified the location where to find my
credential cache and to change that behaviour without warning
is just evil. Look at the following two scenarios:

Day1:
kinit -l1d ***@REALM2
KRB5CCNAME=FILE:/tmp/my-batch-job-credentials kinit -l1w ***@REALM1
KRB5CCNAME=FILE:/tmp/my-batch-job-credentials run-batchjob &
# work all day with things in REALM2
kdestroy
#batchjob works

Day2:
kinit -l1d ***@REALM1
KRB5CCNAME=FILE:/tmp/my-batch-job-credentials kinit -l1w ***@REALM1
# work all day with things in REALM1
kdestroy
#batchjob crashes

Now try to explain that to the user. User says: "Kerberos is evil and
lets my jobs crash. I hate Kerberos and will do everything in my power
that Kerberos will not be used in my academic environment any more."

Harald.

[Harald Barth]

I must admit that this is the same problem that Lars-Johan (hejhej)
asked almost a year ago in "KRB5CCNAME new semantics under Maverick?"
and which I did not read because of "Maverick" in the title (no, I
don't use that, so I kindof thought: "not my problem").

Greg explained how this is supposed to work:

Longer answer: KRB5CCNAME determines the default credential cache name,
but kinit doesn't always use the default credential cache.

As long as FILE: does not support switching (I really don't see why it
could not made to support it, it's just a container for many tickets,
but that's not what this discussion is about) I don't want kinit to
switch to anything that is another file depending on what credential
cache I used earlier for maybe some completely different reason.

If I decide: Now I want to use a DIR: type cache and say so by setting
KRB5CCNAME accordingly, why should kinit for _one_ credential I used
before that, stick to the FILE: cache?

When this happens, the output of klist is really confusing:

***@habanero ~ $ klist -l
Name Cache name Expires
***@STACKEN.KTH.SE FILE:/tmp/krb5cc_18118 Mar 12 09:56:47 2015
***@habanero ~ $ klist
Credentials cache: DIR::/tmp/haba1/tkt
Principal: ***@NADA.KTH.SE

Issued Expires Principal
Mar 11 23:57:32 2015 Mar 12 09:57:28 2015 krbtgt/***@NADA.KTH.SE

How is this cache switching supposed to work anyway (now testing with
a cache type that supports that):

***@habanero ~ $ export KRB5CCNAME=DIR:/tmp/haba1
***@habanero ~ $ kinit haba
***@STACKEN.KTH.SE's Password:
***@habanero ~ $ klist
Credentials cache: DIR::/tmp/haba1/tkt
Principal: ***@STACKEN.KTH.SE

Issued Expires Principal
Mar 12 00:04:05 2015 Mar 12 10:04:02 2015 krbtgt/***@STACKEN.KTH.SE
***@habanero ~ $ klist -l
Name Cache name Expires
***@habanero ~ $ kswitch -i
kswitch: krb5_cc_cache_get_first: Bad format in credentials cache

So now I have the following situation:

1. The traditional way of switching caches reliably does not work any
more unless I use some really ugly things like patching the source
or writing a wrapper to kinit that always does kinit -c $KRB5CCNAME

2. The new way of switching caches with the new DIR: type cache
and kswitch does not work.

Greg wrote almost a year ago:

Well, I am responsible for implementing similar collection behavior in
MIT krb5 1.10, so you can blame me for that. (The MIT krb5 kinit
follows slightly different rules for selecting its output ccache. In
step 1, it only scans the collection if the default cache type supports
switching. In step 2, if the default ccache hasn't been initialized,
kinit will use that in preference to creating a new one.)

The "slightly different" behaviour of different flavours of kinit will
NOT MAKE SUPPORT HAPPY. Just not doing any "scanning the collection"
for FILE: type caches makes sense. Not touching /tmp/krb5cc_<UID> when
KRB5CCNAME is set to anything makes sense to me as well. So if this
scanning around in cache types that support the feature makes some
users happy, could we please leave the traditional behaviour of FILE:
caches as it always has been? This is what the MIT behaviour might do
(I have not tested).

Harald.

PS: Where is the documentation (besides Greg's emails)?

[Greg Hudson]

Post by Harald Barth
I must admit that this is the same problem that Lars-Johan (hejhej)
asked almost a year ago in "KRB5CCNAME new semantics under Maverick?"

The part I am confused about is that FILE:/tmp/krb5cc_UID is appearing
in the collection when KRB5CCNAME is set to something else. That
wouldn't be the case in MIT krb5 and it doesn't match my reading of the
current Heimdal code. But other people have also observed this
behavior, so I must just not be finding the right piece of code (or it
changed recently).