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

Re: Another line-length issue

On Tue, Jul 31, 2001 at 01:30:23AM +0200, Assar Westerlund wrote:
> > kadmin/load.c uses a statically sized 1kb buffer to read lines in.  This
> > causes problems with principals with large numbers of keys.  The naive fix
> > is just to bump the buffer up to some unreasonably large size like 8kb, I'm
> > sure someone else can do something a bit more elegant.
> To begin with, Johan has incorporated your fix.

This unfortunately seems to be a somewhat endemic problem in Heimdal.
Something new in 0.4a or 0.4c has started croaking on me -

<griffon>KeyserSoze-pts/17[2]~$ kadmin -p myuser/admin list \*
muser/admin@REALM.ORG's Password:
  foo@REALM.ORG
  bar@REALM.ORG
...
kadmin: get bad1@REALM.ORG: Communication failure with server
kadmin: get bad2@REALM.ORG: Communication failure with server

This used to (0.3f) work.  Investigating bad1 and bad2 (with kadmin -l which
works fine) makes me suspect that it's again a buffer length issue since
they both have "lots" of keytypes. However, some principals with "lots" of
keytypes work so I'm not entirely sure.  Unfortunately (?) nothing segfaults
and my limitted knowledge of the code makes me somewhat hesitant to start
chasing this.  I arrived previously at many principals which this problem
with this in my krb5.conf (attempting to be flexible about things):

[kadmin]
  default_keys = v4 v5 afs3-salt afs3-salt:REALM.ORG arcfour:pw-salt

The arcfour:pw-salt seems to behave mostly like a second ``v5'' to my
untrained eye, adding what seems to be identical keytypes to the principal.
I'll continue to try to chase these problems as I hit them but it might be
fruitful for someone with more knowledge/time than I to generate one of
these troublesome principals so that there are more eyes on the problem,
especially since these buffer problems seem to still be creeping into
Heimdal.  The kadmin load problem is somewhat tricky since fgets() doesn't
lend itself well to a solution except if one starts doing realloc()s and
fgets in a loop when necessary which is somewhat nasty.  Perhaps in the
short term simply doing a grep for 1024 and replacing suspicious occurances
with 8192 would be helpful?  Or maybe a macro defined in a header file
(HEIMDAL_BUFLEN?) which could be easily reduced to a small value for
debugging perposes would be helpful?  Would a boneheaded patch like this be
helpful?

-- 

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