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
