[Pkg-dspam-misc] Bug#400301: dspam should not be run with hash drivers in daemon mode

[Daniel Kahn Gillmor]

Package: dspam
Version: 3.6.8-4
Severity: important

Debian currently ships dspam with only the default set of hash storage
drivers.

We also ship /etc/init.d/dspam, which is designed to run dspam in
daemon mode (though it is initally disabled in /etc/default/dspam).

Buried in the /usr/share/doc/dspam/changelog.gz is this:

> [20041130.0800] jonz: dspam daemonized LMTP server and client
>
> added --daemon functionality to put DSPAM into daemonized LMTP
> server mode; configure client in dspam.conf to talk to daemon, or
> speak LMTP without the client. authentication configurable in
> dspam.conf. implemented stateful database connections. --stdout and
> --classify supported.
> 
> NOTE: Daemon mode is multithreaded, and therefore requires a
>       multithreaded driver: mysql_drv or pgsql_drv.

Yikes!  i wish i'd noticed that earlier.  Is it documented anywhere
else that anyone knows?  I just posted to dspam-users that daemon mode
and the hash drivers do not mix:

  http://article.gmane.org/gmane.mail.spam.dspam.user/12032

but the debian packages should make that clear as well.  Because of
the non-threadsafe fcntl-locking used in the hash driver, daemon mode
can cause corruption of the hash tables if two concurrent threads
access it at once.

I plan on an initial workaround for this by adding strong words in
/etc/default/dspam.

I'd like to follow that up temporarily with a check in the dspam
source that declines to run in daemon mode if the configuration tells
it to use the hash storage drivers (maybe just testing if
StorageDriver ends in libhash_drv.so?)

The right way to fix this would be to add a function to all storage
driver libraries which declares thread-safety.  Then we should modify
dspam itself to decline to run in daemon mode if the storage driver
doesn't report thread-safety properly.  

I'm not sure how this change would affect our dspam package, because
it would be a new function that we'd expect the libraries to provide.
After the first two workarounds are in place, i'll look into what
packaging gymnastics that sort of library transition would require.

If anyone has any other suggestions, i'm all ears!

Thanks,

	--dkg

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages dspam depends on:
ii  adduser                     3.99         Add and remove users and groups
ii  libc6                       2.3.6.ds1-8  GNU C Library: Shared libraries
ii  libdspam7                   3.6.8-4      DSPAM is a scalable and statistica
ii  libldap2                    2.1.30-13+b1 OpenLDAP libraries
ii  procmail                    3.22-16      Versatile e-mail processor
ii  sensible-mda                8.13.8-2     Mail Delivery Agent wrapper

Versions of packages dspam recommends:
pn  clamav-daemon                 <none>     (no description available)
ii  dspam-doc                     3.6.8-4    Documentation for dspam

-- no debconf information