On Thu, Sep 17, 2009 at 5:05 PM, Greg Hudson<[email protected]> wrote: > On Thu, 2009-09-17 at 13:03 -0400, [email protected] 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 [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
