Bug#563492: Debian-exim can't write to /var/spool/sa-exim/tuplets
On Sunday, 3 January 2010, Andrew Archibald wrote: Greylisting in the latest stable sa-exim doesn't appear to work with the default permissions on the tuplets directory left by a d-i fresh install, using the 'Mail server' software collection option. # ls -ld /var/spool/sa-exim/tuplets/ drwxr-x--- 2 nobody Debian-exim 4096 2009-12-17 11:20 /var/spool/sa-exim/tuplets/ It seems that reconfiguring, as below, tidies up the perms. # dpkg-reconfigure sa-exim Reloading exim4 configuration files: exim4. # ls -ld /var/spool/sa-exim/tuplets drwxrwx--x 2 nobody Debian-exim 4096 2009-12-17 11:20 /var/spool/sa-exim/tuplets Yes, that the permissions where set differently the first time than on subsequent invokations was a bug. The default of running the greylistclean as nobody also surprised me. With Debian-exim writing to the tuplets dir, nobody didn't have enough access: nobody@myhost:/$ /usr/share/sa-exim/greylistclean Can't cd to (/var/spool/sa-exim/tuplets/) 92: Permission denied at /usr/share/sa-exim/greylistclean line 79 Well, the default setup relies on you running spamd as nobody, as described in README.greylisting. That is, however, not really a great idea - nobody shouldn't own any files IIUC - so I'll change the package to work with the default setup of spamd and add more information to the README files. I'll try to make it so that existing installations won't be broken... -- Magnus Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#563492: Debian-exim can't write to /var/spool/sa-exim/tuplets
Package: sa-exim Version: 4.2.1-11 Severity: normal Greylisting in the latest stable sa-exim doesn't appear to work with the default permissions on the tuplets directory left by a d-i fresh install, using the 'Mail server' software collection option. # ls -ld /var/spool/sa-exim/tuplets/ drwxr-x--- 2 nobody Debian-exim 4096 2009-12-17 11:20 /var/spool/sa-exim/tuplets/ It seems that reconfiguring, as below, tidies up the perms. # dpkg-reconfigure sa-exim Reloading exim4 configuration files: exim4. # ls -ld /var/spool/sa-exim/tuplets drwxrwx--x 2 nobody Debian-exim 4096 2009-12-17 11:20 /var/spool/sa-exim/tuplets The default of running the greylistclean as nobody also surprised me. With Debian-exim writing to the tuplets dir, nobody didn't have enough access: nob...@myhost:/$ /usr/share/sa-exim/greylistclean Can't cd to (/var/spool/sa-exim/tuplets/) 92: Permission denied at /usr/share/sa-exim/greylistclean line 79 I needed the following to get the clean working. # sed -i 's/* nobody/* Debian-exim/' /etc/cron.d/greylistclean This looks a little like archived bug 359869 but that was closed on 4.2.1-2, in 2006. Cheers, Andrew. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sa-exim depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii exim4-daemon-light [exim4 4.69-9 lightweight Exim MTA (v4) daemon ii libc6 2.7-18 GNU C Library: Shared libraries ii spamc 3.2.5-2+lenny1 Client for SpamAssassin spam filte Versions of packages sa-exim recommends: ii perl 5.10.0-19lenny2 Larry Wall's Practical Extraction Versions of packages sa-exim suggests: ii spamassassin 3.2.5-2+lenny1 Perl-based spam filter using text -- debconf information: sa-exim/purge_spool: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
