Zero-length entry in a keytab: why?! kerberos at
Thu Sep 17 13:03:20 EDT 2009


I came across an issue when working with the keytab file format
(0x502).  My code follows the instructions at and I've been able to
parse/verify all the keytabs in my environment -- until today -- when
I came across a keytab whose int32_t size for a particular entry was
*zero*, not a negative number, but *zero*.

This caused my code to explode and not be able to parse the keytab any
further -- even tho I can use klist and ktutil to read the keytab and
can kinit using the same keytab.  Following the keytab format
document, I'd expect that "holes" in a keytab would be represented by
a negative number and by using an unsigned integer I'd just read X
bytes to get to the next entry.  However, the zero length of my entry
is really throwing me off because I'm not sure if I should seek(...)
forwards or backwards to read the next entry or if there is another
way to deal with a zero-length entry or if it's all a lost cause or
what have you.

Why might the entry length be zero?  And if the zero does indeed
represent a hole in the keytab, how many bytes do I have to read to
skip the hole and move to the next entry?


More information about the Kerberos mailing list