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