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

Valerie (Yu-Ching) Peng valerie.peng at oracle.com
Wed Aug 7 20:45:22 UTC 2013


Was catching up on other tasks, will come back to this today or tomorrow...
Thanks,
Valerie

On 08/06/13 20:49, Weijun Wang wrote:
> Ping again.
>
> On 7/29/13 5:11 PM, Weijun Wang 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




More information about the security-dev mailing list