[31484] in Kerberos
Zero-length entry in a keytab: why?!
daemon@ATHENA.MIT.EDU (kerberos@noopy.org)
Thu Sep 17 13:04:01 2009
MIME-Version: 1.0
Date: Thu, 17 Sep 2009 13:03:20 -0400
Message-ID: <cba4e37e0909171003m1afdda2ekb97031cc6758ad26@mail.gmail.com>
From: kerberos@noopy.org
To: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Hello,
I came across an issue when working with the keytab file format
(0x502). My code follows the instructions at
http://www.ioplex.com/utilities/keytab.txt 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?
--
K
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
