+++ This bug was initially created as a clone of Bug #1199363 +++

Basically, on the box that I originally logged into (via KDM):

> klist
Ticket cache: KEYRING:persistent:7225:krb_ccache_8LMqrkh
Default principal: tibbs.EDU

Valid starting       Expires              Service principal
03/05/2015 21:19:44  03/06/2015 21:19:44  krbtgt/MATH.UH.EDU.EDU
        renew until 03/12/2015 20:44:18

I can kinit to another principal:

> kinit tibbs/admin
Password for tibbs/admin.EDU:

Now, if I first ssh to another host:

> ssh ld01
Last login: Thu Mar  5 21:25:03 2015 from epithumia.e.math.uh.edu

ld01:~> klist
Ticket cache: KEYRING:persistent:7225:7225
Default principal: tibbs.EDU

Valid starting       Expires              Service principal
03/05/2015 21:25:16  03/06/2015 21:19:44  krbtgt/MATH.UH.EDU.EDU
        renew until 03/12/2015 20:44:18

Then I can't kinit to another principal:

ld01:~> kinit tibbs/admin
kinit: Can't create new subsidiary cache because default cache is already a subsdiary while generating new ccache

Simo seems to know what's up and asked me to file a bug.  I'm running updated F21; here are some hopefully relevant versions:

krb5-libs-1.12.2-9.fc21.x86_64
openssh-6.6.1p1-11.1.fc21.x86_64
pam_krb5-2.4.9-3.fc21.x86_64
pam-1.1.8-16.fc21.x86_64
kernel-3.18.7-200.fc21.x86_64

--- Additional comment from Jakub Jelen on 2015-03-17 08:22:47 EDT ---

OK. I can reproduce it on my machine. It also appears when you try to kinit to different user (not only principal).

When you try to list tickets with flags (klist -f), you will see that the last ticket has a "f" flag, which means that it is forwarded (and used for authentication for this host?) so you probably can't overwrite it with different ticket?
seems to be related to this one: bz974947


Simo? What do you think? What is expected behaviour?

Just tested with DIR ccache and I'm unable to get the forwarded ticket on second server.

--- Additional comment from Simo Sorce on 2015-03-17 09:13:23 EDT ---

(In reply to Jakub Jelen from comment #1)
> OK. I can reproduce it on my machine. It also appears when you try to kinit
> to different user (not only principal).
> 
> When you try to list tickets with flags (klist -f), you will see that the
> last ticket has a "f" flag, which means that it is forwarded (and used for
> authentication for this host?) so you probably can't overwrite it with
> different ticket?
> seems to be related to this one: bz974947
> 
> 
> Simo? What do you think? What is expected behaviour?
> 
> Just tested with DIR ccache and I'm unable to get the forwarded ticket on
> second server.

It's a tricky situation, on the one hand it may make sense to have a subsidiary cache, on the other it causes a number of restrictions we shouldn't really suffer.

We probably need to discuss what are the expectations as an ssh user and see if we need some tunables or not.

My initial thinking is that, if you have a Cache Collection, what you can do is to stick the delegated credentials in a subsidiary, but still put the whole collection in KRB5CCNAME and just kswitch to the newly stored credentials as the default creds.
However, if you are already logged into the console or from another ssh session, doing a kswitch will affect all terminals, so I am hesitant.

Perhaps, it should be a tunable where you can tell sshd what is the preference: stick to subsidiary vs expose the whole collection.

--- Additional comment from Jakub Jelen on 2015-03-26 12:14:23 EDT ---

OK. I had the second look at this issue and from my point of view, we should do it all the same way how the FILE and DIR cache does it. My testing with different default_ccache_name showed that you can do the above mentioned kinit with all the other configurations:
http://paste.fedoraproject.org/203252/27382909/

So only KEYRING is set up as subsidiary cache.

There is no reason to block kinit, because there is workaround to use "kdestroy; kinit user" to change to different principal.

sshd is handling ccache by hand and KEYRING is supported after this bz991186. We are using functions krb5_cc_initialize, krb5_cc_store_cred from krb5.h so if I'm right we can

Unfortunately, there is not much documentation about KEYRING ccache. I don't think that we specify somewhere it it should be subsidiary or do handle this cache different than the others. If it is a bug, probably in krb5 libraries IMHO.

--- Additional comment from Jason Tibbitts on 2015-03-26 12:46:47 EDT ---

Unfortunately the workaround of "kdestroy; kinit whatever" has implications for kerberized NFS so it's not entirely a perfect solution, but I can deal either way.  I just thought it was odd that whether you can kinit depends on both your ccache type and how you happened to log in.

--- Additional comment from Simo Sorce on 2015-03-26 13:33:14 EDT ---

Ok I think we can move this to krb5, if the KEYRING ccache behaves subnstantially differently than a FILE/DIR ccache we may consider it a KEYRING ccache bug indeed.

--- Additional comment from Roland Mainz on 2015-03-26 19:52:17 EDT ---

(In reply to Simo Sorce from comment #5)
> Ok I think we can move this to krb5, if the KEYRING ccache behaves
> subnstantially differently than a FILE/DIR ccache we may consider it a
> KEYRING ccache bug indeed.

Who wrote the initial KEYRING support in krb5 ?

--- Additional comment from Simo Sorce on 2015-03-27 09:13:31 EDT ---

(In reply to Roland Mainz from comment #6)
> Who wrote the initial KEYRING support in krb5 ?

I think Nalin did the old KEYRING code, and I refactored it heavily to make it a Collection Type.

--- Additional comment from Nalin Dahyabhai on 2015-03-27 09:47:20 EDT ---

You flatter me.  The git log attributes it to Kevin Coffman.

--- Additional comment from Charles Slivkoff on 2015-06-01 11:20:32 EDT ---

This is also an issue for RHEL 7. 

Is another BZ needed?

--- Additional comment from Fedora End Of Life on 2015-11-04 05:36:30 EST ---

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.