amavisd stops after reload
hans at dailystuff.nl
Sat Jul 27 16:39:54 CEST 2013
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 
> and then nothing a no one amavisd process
> full log is here (without any working child which generate lot of lines)
> > 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
> -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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the amavis-users