[31487] in Kerberos
Re: Zero-length entry in a keytab: why?!
daemon@ATHENA.MIT.EDU (Ezra Peisach)
Thu Sep 17 21:55:44 2009
Message-ID: <4AB2D585.5050700@mit.edu>
Date: Thu, 17 Sep 2009 20:34:13 -0400
From: Ezra Peisach <epeisach@mit.edu>
MIME-Version: 1.0
To: kerberos@noopy.edu
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Howdy,
a) You describe a variable bytesRemain - neither MIT nor Heimdal use
such a variable - so this might be your code.
b) You mention a vendor app writing such a keytab with holes - care to
mention who? I suspect they might have extended their definition of a
keytab in a non-standard way... You can ask the vendor...
c) If the size field is 0, I can envision that this means the rest of
the structure is empty. I agree with Greg in a preliminary reading of
the MIT code that a size of zero is treated as an end of keytab. A quick
reading of Heimdal's code looks like it would ignore the size field
being zero and try to continue parsing the keytab until EOF. Shishi does
not handle negative sizes....
d) Heimdal has another extension -after the version number, if there are
4 bytes - a flag for the entry can be stored.... Not sure off hand what
for...
e) You mention that klist and ktutil can read the keytab - which vendor
program are you using? I suspect not MIT.
So - I suspect that this might be caused by some vendor's interpretation
of a keytab...
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
