code review request: 7019384: Realm.getRealmsList returns realms list in wrong (reverse) order

Weijun Wang weijun.wang at oracle.com
Mon Mar 28 05:26:16 UTC 2011


Hi Xuelei

We fixed an [capaths] bug some time ago:

    6789935: cross-realm capath search error
    http://hg.openjdk.java.net/jdk7/tl/jdk/rev/33bc32405045

Unfortunately, it's still not correct. Here is a new webrev:

    http://cr.openjdk.java.net/~weijun/7019384/webrev.00/

As described in the bug report, we searched paths from target(sRealm) to 
initiator(cRealm), but the capaths returned by the method *should* be 
from cRealm to sRealm.

I reversed the tempList in the fix.

Also, the first item in tempList is now sRealm, this order has a 
consistent meaning, and avoids some extra loop check.

Another "!intermediaries.equals(cRealm)" check is added to be more robust.

Thanks
Max

-------- Original Message --------
*Change Request ID*: 7019384
*Synopsis*: Realm.getRealmsList returns realms list in wrong (reverse) order


=== *Description* 
============================================================
FULL PRODUCT VERSION :
Checked on Java SE 6.23 and OpenJDK 7.

A DESCRIPTION OF THE PROBLEM :
sun.security.krb5.Realm.getRealmsList returns realms list in wrong order:
- cRealm is always first (this is OK)
- the rest however is in reverse order

For one intermediate realm nothing happens. For two or more intermediate 
realms sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds 
traverses realms in wrong order and cann't get service ticket.

Checked on Java SE 6.23 and OpenJDK 7.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
[capaths]
A9.PRAGUE.XXX.CZ = {
  PRAGUE.XXX.CZ = .
  ROOT.XXX.CZ = PRAGUE.XXX.CZ
  SERVIS.XXX.CZ = ROOT.XXX.CZ
}

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
>>> Realm parseCapaths [0]=A9.PRAGUE.XXX.CZ
>>> Realm parseCapaths [1]=PRAGUE.XXX.CZ
>>> Realm parseCapaths [2]=ROOT.XXX.CZ

ACTUAL -
>>> Realm parseCapaths [0]=A9.PRAGUE.XXX.CZ
>>> Realm parseCapaths [1]=ROOT.XXX.CZ
>>> Realm parseCapaths [2]=PRAGUE.XXX.CZ

ERROR MESSAGES/STACK TRACES THAT OCCUR :
>>> Realm doInitialParse: cRealm=[A9.PRAGUE.XXX.CZ], sRealm=[SERVIS.XXX.CZ]
>>> Realm parseCapaths: loop 1: target=SERVIS.XXX.CZ
>>> Realm parseCapaths: loop 1: intermediaries=[ROOT.XXX.CZ]
>>> Realm parseCapaths: loop 1: pushed realm on to stack: ROOT.XXX.CZ
>>> Realm parseCapaths: loop 1: added intermediary to list: ROOT.XXX.CZ
>>> Realm parseCapaths: loop 2: target=ROOT.XXX.CZ
>>> Realm parseCapaths: loop 2: intermediaries=[PRAGUE.XXX.CZ]
>>> Realm parseCapaths: loop 2: pushed realm on to stack: PRAGUE.XXX.CZ
>>> Realm parseCapaths: loop 2: added intermediary to list: PRAGUE.XXX.CZ
>>> Realm parseCapaths: loop 3: target=PRAGUE.XXX.CZ
>>> Realm parseCapaths: loop 3: no intermediaries
>>> Realm parseCapaths [0]=A9.PRAGUE.XXX.CZ
>>> Realm parseCapaths [1]=ROOT.XXX.CZ
>>> Realm parseCapaths [2]=PRAGUE.XXX.CZ

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Enhancements for OpenJDK 7 test suite:

Add to b/test/sun/security/krb5/krb5-capaths.conf:

[capaths]
A9.PRAGUE.XXX.CZ = {
  PRAGUE.XXX.CZ = .
  ROOT.XXX.CZ = PRAGUE.XXX.CZ
  SERVIS.XXX.CZ = ROOT.XXX.CZ
}


Add to b/test/sun/security/krb5/ParseCAPaths.java:

// Multiple intermediate realms
check("A9.PRAGUE.XXX.CZ", "SERVIS.XXX.CZ", "A9.PRAGUE.XXX.CZ", 
"PRAGUE.XXX.CZ", "ROOT.XXX.CZ");



More information about the security-dev mailing list