Package: dspam Version: 3.6.6-1 Severity: wishlist Tags: patch
dspam appears to actually be able to be much more than a spam filter.
it can be a full-fledged classifier for arbitrary content.
The way that the debian dspam package is installed is a pretty good
strategy for using it as a spam filter, but it doesn't allow non-root
users on the system to set up their own dspam-based classifiers or to
experiment with different settings without damaging their one account,
due to the centralized nature of the install, and the setgid binary.
Also, you can't run two independent dspam daemons on one debian system
at the moment and have them each use different configuration files.
One way to allow these kinds of use without breaking the current setup
is to allow the various dspam binaries to read from an alternate
configuration file. Obviously, reading from an alternate
configuration file as featureful as dspam's (e.g. loading arbitrary
libraries) is a security risk for setuid or setgid executables.
My proposal is that the environment variable DSPAM_CONF could be used
to point to a preferred config file. If DSPAM_CONF is present and
non-empty, dspam (and all related binaries) will read from the
alternate file. Any binary that is setuid or setgid would drop
privileges back to the real uid/gid in the presence of an alternate
configuration file.
The patch i'm providing attempts to implement this strategy. It
should apply cleanly at the end of the current dpatch set.
It also modifies all the upstream-provided man pages to describe the
new functionality. i'm happy to patch the debian-provided manpages as
well, if folks think this is a strategy worth keeping.
Thanks,
--dkg
PS one thing i'm not clear about from a security perspective is how
this patch will affect the dspam client/daemon interaction. Can
someone who understands that interaction better than myself weigh in
on this? What happens if a client is running with a different config
file than the daemon it talks to? Will this be a problem?
PPS i have an alternate implementation of this patch which uses a
command line argument (--config=/wherever) instead of an environment
variable. After a bit of playing around with it, i think i like the
environment variable patch better than the argument patch, for a few
reasons:
0) writing your own classifier on top of dspam as a set of scripts
would be easier if you could just set an environment variable
rather than having to supply the same argument over and over
again,
1) programs which already contain nested calls to dspam should adapt
to changes in the environment without modifying their internal
calls to dspam, and
2) the dspam argument handling code appears to vary from binary to
binary, and i don't want to break it too much. (e.g. dspam_admin
doesn't currently accept any --long-arguments, while dspam itself
does)
However, if other folks prefer the command-line argument strategy,
i'll provide that patchset instead.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (700, 'testing'), (700, 'stable'), (600, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages dspam depends on:
ii adduser 3.87 Add and remove users and groups
ii libc6 2.3.6-7 GNU C Library: Shared libraries
ii libdspam7 3.6.6-1 DSPAM is a scalable and statistica
ii libldap2 2.1.30-13 OpenLDAP libraries
ii procmail 3.22-16 Versatile e-mail processor
Versions of packages dspam recommends:
pn clamav-daemon <none> (no description available)
ii dspam-doc 3.6.4-4 Documentation for dspam
-- no debconf information
allow-alternate-config.dpatch
Description: application/shellscript
