[31486] in Kerberos
Re: Zero-length entry in a keytab: why?!
daemon@ATHENA.MIT.EDU (kerberos@noopy.org)
Thu Sep 17 17:34:15 2009
MIME-Version: 1.0
In-Reply-To: <1253221531.9347.47.camel@ray>
Date: Thu, 17 Sep 2009 17:33:37 -0400
Message-ID: <cba4e37e0909171433r578c674bu6578ed0c9ab3615b@mail.gmail.com>
From: kerberos@noopy.org
To: Greg Hudson <ghudson@mit.edu>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, Sep 17, 2009 at 5:05 PM, Greg Hudson<ghudson@mit.edu> wrote:
> On Thu, 2009-09-17 at 13:03 -0400, kerberos@noopy.org wrote:
>> 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?
>
> By my reading of the MIT krb5 code, you can treat a zero-value length
> entry as the end of the keytab. (I wasn't able to figure out any normal
> sequence of events which would lead to such an entry in our code base,
> but I didn't look too hard.)
Unfortunately for me the zero-value entry appears somewhere in the
middle of the keytab! Arggh!
Looking at my code further, if I assign a bytesRemain variable to
entryLength and decrement bytesRemain by bytesRead each time I read an
item from a keytab entry I've noticed there are *definitely* holes
throughout the keytab -- or at very least chunks that I can't explain
-- such that (bytesRemain > 0) for some but not all entries. During
this re-examination I thought bytesRemain might actually represent
uint32_t vno but the size of bytesRemain varies greatly (sometimes 5,
sometimes 8, sometimes whatever else) so I am not sure that I'm seeing
vno. As described in http://www.ioplex.com/utilities/keytab.txt:
"The last field of the keytab_entry structure is optional. If the size of
the keytab_entry indicates that there are at least 4 bytes remaining,
a 32 bit value representing the key version number is present. "
When I modify my code to seek(...) bytesRemain positions ahead, I can
get further in reading the keytab than I did previously but it still
ends up barfing someplace or another.
What are your thoughts about me actually forgetting to deal with vno
hence the "holes" I'm seeing? Also, if I'm understanding vno
correctly, how would it even be possible for a 32-bit value to be 8,
15, or 24 characters long?! :-)
FWIW, for the keytabs that I write *myself* I *never* have the problem
I'm explaining here. This keytab was created by one of our vendor's
apps and something is amiss.
--
K
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
