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