As subject. Looking at the code it looks like it's because when the krb4
code in keytab_krb4.c opens the file (krb4_kt_start_seq_get_int) it doesn't
need to read anything in. In contrast, fkt_start_seq_get_int, the krb5
equivelent, has to read some header stuff from the keytab and therefore
chokes when it can't. However, the krb5 stuff chokes if you create an empty
keytab and try to list it as well:
<root>KeyserSoze-pts/6[3]~/lsrc/heimdal-0.3f/admin/.libs# ktutil -k /tmp/kt
list
Vno Type Principal
4 des-cbc-crc host/keysersoze.snurgle.org
3 des-cbc-crc ftp/keysersoze.snurgle.org
<root>KeyserSoze-pts/6[4]~/lsrc/heimdal-0.3f/admin/.libs# ktutil -k /tmp/kt
remove -e des-cbc-crc
<root>KeyserSoze-pts/6[5]~/lsrc/heimdal-0.3f/admin/.libs# ktutil -k /tmp/kt
list
Vno Type Principal
Segmentation fault (core dumped)
<root>KeyserSoze-pts/6[6]~/lsrc/heimdal-0.3f/admin/.libs# ls -l /tmp/kt
-rw------- 1 root root 141 Mar 8 22:13 /tmp/kt
The problem is that in kt_list (admin/list.c), ki is never initialized if no
keys are read from the keytab, but it merrily tries to walk the linked list
anyhow at the bottom. The trivial fix is to initialize ki to NULL up at the
declaration. I don't know if there's some more elegant way to detect that
there were no keys read; krb5_kt_end_seq_get seems to return 0 in that case
and in any case the return value is discarded.
--
..ooOO chris@chiappa.net | My opinions are my own OOoo..
..ooOO Chris.Chiappa@oracle.com | and certainly not those OOoo..
..ooOO http://www.chiappa.net/~chris/ | of my employer OOoo..