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

[Valerie (Yu-Ching) Peng]

The changes look fine - I don't care for supporting the chaining since 
it complicates up the parsing code very much. Oh-well.
But at least the new code is way shorter than the older one.
It's unfortunate that in order to support this chaining, we ended up 
wasting more cycles processing the whole thing.
Otherwise, one config.getAll(...) call would have been sufficient, if 
the config is properly written in MIT's syntax.

Valerie

On 08/28/13 12:04, Henry B. Hotz wrote:
> 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