Brian Ristuccia wrote:
Package: clamsmtp
Version: 1.2-3
Severity: serious
The init.d script for clamsmtp breaks with start-stop-daemon in dpkg
(1.9.21) because it doesn't provide the --group option. It needs to use one
of the various dependancy mechanisms to make sure a newer dpkg providing
this option gets upgraded on install. Clamsmtp doesn't work unless the
init.d script is manually edited or dpkg is manually upgraded.
Although, I agree that this is a policy error, the scope of the error
only applies to back porting the package. In any case, I added the
dependency checking to the control file as suggested.
I've been debating whether or not to add a dedicated system user and
group for clamsmtp for a number of reasons. Although there is no policy
mandating daemons run as their own user and group, doing so might make
things a bit more flexible and secure for the daemon.
Now that clamsmtp can actually run scripts, I'm not too comfortable
having it run as clamav:clamav. A systems administrator may have added
the clamav user to priveleged groups for scanning protected filesystems.
A poorly written and exploited script run from clamsmtp may now have
access to these documents. Granted, it might not be likely such an
attack would be probable or even successful, there's no reason to tempt
fate.
Essentially, if I were to add a clamsmtp:clamsmtp user/group and add
clamav to the clamsmtp group so it would have access to the quarantine
directory, I wouldn't need to worry about the --group switch to
start-stop-daemon. As a result, the package would be easier to
back-port to sarge.
There is some fragility to this setup, in the face of system
administrator customizations. However, we can be reasonably certain
that the user and group clamav:clamav will be install.
--
Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
signature.asc
Description: Digital signature
