Code review request: 8012615: Realm.getRealmsList returns realms list in wrong

[Henry B. Hotz]

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.wang at 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 at A, and then fallback to krbtgt/D at A, krbtgt/C at A and krbtgt/B at A. In fact, since the capath is already there, krbtgt/B at 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 at 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 at K1, krbtgt/K3 at K2, krbtgt/K4 at K3, krbtgt/K5 at K4 and finally get service ticket to host/host.k5 at K5. Now Java can do the same with the same krb5.conf.
> 
> Thanks
> Max