[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ktutil -k krb4:/dev/null list segfaults

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
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
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..