Looks fine to me. Good to have for compatibility. Xuelei
On 12/17/2012 10:25 AM, Weijun Wang wrote: > Xuelei or Valerie, > > Can you review this code change? Some customers really likes this fallback. > > Thanks > Max > > On 09/09/2012 06:27 PM, Weijun Wang wrote: >> Please take a review at this >> >> http://cr.openjdk.java.net/~weijun/7197159/webrev.00/ >> >> In 6893158, we started kvno checking when parsing AP-REQ. Since then, we >> have compatibility reports that keytab created with JDK's ktab.exe fail >> because of this change. In 6984764, we added an option to ktab.exe so >> that users can specify the correct kvno when creating a keytab, but it >> seems not enough. >> >> This fix adds another fallback to the kvno check. If none of the keys in >> a keytab matches the required kvno, instead of reporting a >> KRB_AP_ERR_BADKEYVER error, we now returns a key of the same etype with >> the highest kvno. >> >> Hope this stops the compatibility problem. >> >> *Mala*: this is the alternative way I propose to solve the problem. It >> should be applicable to 6u and 7u. >> >> Thanks >> Max >> >> >> -------- Original Message -------- >> 7197159: accept different kvno if there no match >> >> === *Description* >> ============================================================ >> 6893158 introduced kvno (key version number) check in AP-REQ parsing. >> This is a correct behavior but might cause interop/compatibility >> problems if the server uses a keytab with wrong kvno values. In fact, >> our vey own ktab.exe tool included in JDK can generate such keytab files >> because it does not know what the correct kvno is. (Other keytab >> generation tools like the kadmin or ktpass know the correct kvno because >> they need to connect to the KDC to work, but ktab.exe is a completely >> standalone tool) >> >> Through 6984764, we've updated the ktab.exe tool so that user can >> specify the correct kvno on the command line, or specify it as 0 if it's >> unknown (0 will be accepted by the check). However, first it's quite >> difficult to find out the correct kvno. Second, there are old kaytab >> files that just contain wrong kvno. >> >> This fix intends to add a fallback to the kvno checking, that when no >> key with matched kvno can be found, we will return the key of the same >> etype with the highest kvno, hoping it's the last one added to the >> keytab and therefore likely to be also the latest. >>
