Martin Fuxa schreef op vr 26-07-2013 om 22:51 [+0200]: > On 06/12/2013 01:20 PM, Andreas Schulze wrote: > > Am 12.06.2013 10:03 schrieb Martin Fuxa: > >> and HUP is not performed. > > you may set $log_level = 5, restart, then reload and watch the log. > > > > I don't see any reason in log > last line > Signalling a SIGHUP to a running daemon [22281] > and then nothing a no one amavisd process > > full log is here (without any working child which generate lot of lines) > http://pastebin.com/g0jvXAq2 > > > > > Usually caused by unreadable files specified somewhere in amavisd.conf. > > For example, these always get me: > > I did not think it (I have some required files in /etc/postfix with > correct permission), but it is my case! > > some admin was paranoid within updated certs > /var/lib/dkim/a.key.pem > /var/lib/dkim/notif-mail.key.pem > -rw------- 1 root root > changed to ... works fine > -rw-r----- 1 root vscan > > > Proper logging in this reload case would be nice.
Looking at the amavisd-new code one can find the following line:
$fh->open(untaint($fname), O_CREAT|O_EXCL|O_RDWR, 0600)
This looks fine at first, but will make the certificates in most
installations writable by the amavisd-new process itself, a remote
accessible process. So maybe a more relaxed model can be implemented by
making the file 0640 instead of 0600 and follow the user and group model
Debian is using of it's SSL-certificates. The certificates are owned by
root, but readable for everyone in de group amavis for example. And is
one is worried about forgetting a chgrp amavis every time he or she
generates a new certificate, a directory with 2750 and belonging to
root:amavis solves that case as well as the group of the directory will
be enforced on new files.
This will make most "paranoid" sysadmins and/or security officers happy
and your installation running.
Hans
signature.asc
Description: This is a digitally signed message part
