On Thu, 8 Jul 1999, Olaf Titz wrote:
> The traditional dbm API deals with "datums" as binary blocks represented
> as pointer/length pairs, not as C strings. The length attribute has to
> be stored in the dbm file anyway, so the proper representation for
> string-formed data should be without the trailing nul.
Indeed. However, I seem to recall that I included the nul in the keys
for alias files (which is what dbmbuild was originally created to make)
because these zeros were there in the alias files used by the previous
MTA (which in our case was smail, but I imagine it copied it from
somebody else). Since those early days, the use of DBM lookups has
expanded to cover many other things than just alias files.
I think I probably made the wrong decision way back then, but it's a bit
late to change things now.
> The proper fix
> IMHO would be to change the dbm reading routine in exim to add the nul
> byte or otherwise ensure a cap on string length. (Note that this also
> has to do with avoiding crashes on malformed dbm data.)
Good point. I'll check what it does. That is entirely independent of
whather the nul is included in the key or not.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
