I can't speak to the code, but your description of what *should* happen is correct.
I have no experience with complex X-relam setups (which have security issues even if the code is correct), but I do know that the MIT code does not "nest" its processing of the capath configuration which causes some non-intuitive behavior. I expect that Heimdal does the same thing as MIT, but if you have time it might be nice to confirm that. If there are differences, I would welcome a discussion on the Heimdal list. On Jul 29, 2013, at 2:11 AM, Weijun Wang <weijun.w...@oracle.com> wrote: > Hi Valerie > > Please review the capaths code change at > > http://cr.openjdk.java.net/~weijun/8012615/webrev.01/ > > It includes: > > Config.java > =========== > > Add method to check if a sub-stanza exists. > > Realm.java > ========== > > Rewrite reading cross-realm path for both [capaths] and hierarchy. The > [capaths] part implements the chaining process. > > CredentialsUtils.java > ===================== > > When reading cross-realm TGT for a path A->B->C->D->SERVERREALM, the current > impl first gets krbtgt/SERVERREALM@A, and then fallback to krbtgt/D@A, > krbtgt/C@A and krbtgt/B@A. In fact, since the capath is already there, > krbtgt/B@A should be the first to check. I don't know about the history of > this code and dare not change much. But I at least reverse the order of the > fallback (what the code calls inner loop) to try krbtgt/B@A first. > > Tried on a local setup of 5 MIT KDC realms configured with a one-direction > cross-auth from K1 to K5. The MIT kvno command starts with kinit in K1 and > goes thru krbtgt/K2@K1, krbtgt/K3@K2, krbtgt/K4@K3, krbtgt/K5@K4 and finally > get service ticket to host/host.k5@K5. Now Java can do the same with the same > krb5.conf. > > Thanks > Max
