> Actualy I start with "-c /etc/mail/amavisd.conf" and LC_ALL=C but you > since you asked I added -u vscan and -g vscan and debug gave me the > answer: > The templates werent owned by vscan... :-O > After changing the rights of the templatedir things went a lot smoother. > (wich is odd, shouldn't the uid/gid section in the config file do the > same as specifing it on commandline?)
This hasn't changed since amavisd-new-2.0. From its release notes: - new command line options '-u user' and '-g group' are available. These are pretty much equivalent to doing a su(1) to the specified user first (in which case the use of these options is redundant). By doing 'su' or by specifying a command-line option '-u username' one can prevent a potential security risk on misconfigured sites where amavisd.conf is writable by UID running amavisd (e.g. not owned by root). If a (non-root) username or UID is specified, privileges are now dropped _before_ opening and evaluating a configuration file. The consequence is that the configuration variables $daemon_user and $daemon_group (in amavisd.conf) can not have an after-effect (a warning is issued if different). If -u is not specified, the behaviour is as before, i.e. the config file is read and evaluated under the current UID (as root unless 'su' was done), and the values of $daemon_user and $daemon_group from the config file are passed to Net::Server, which changes UID during its startup after chroot-ing (if requested). If chroot is desired, the -u must not be used: the root privilege is required to do chroot, and the config file must be read _before_ doing chroot. A case of Catch-22. Be doubly careful of who can modify the configuration file. Another consequence of specifying -u is that any external files (e.g. templates, lookup hashes) as possibly read from amavisd.conf, are now accessed as unprivileged user and no longer as root. The same goes for opening the log file when not logging via syslog. > The templates werent owned by vscan... :-O As long as template files are readable by user vscan, they can be owned by any other uid. Preferably files like amavisd.conf and all files read from there by read_text should be owned by root (to avoid a potential risk of being modified by some dearchiver running amock), but readable to user vscan (amavis). > Only 2.4 hangs now on SA: > [4230] dbg: plugin: loading Mail::SpamAssassin::Plugin::URIDNSBL from > @INC > Suicide () TROUBLE in pre_loop_hook: Insecure dependency in eval while > running with -T switch at > /usr/lib/perl5/site_perl/5.8.7/Mail/SpamAssassin/PluginHandler.pm line > 91 Interesting, a 'require' in PluginHandler.pm finds its argument tainted, or perhaps thinks one of the directories in @INC is insecure. > For the new error, do I still proceed as discribed by you? Both problems could originate from the same Perl bug, triggered by some code running before. We had this sort of Perl taint bugs before, but provided a workaround for most if not all of them. I wouldn't mind seing the results from the experiment I suggested in my previous mail - could narrow the bug search area. Mark ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
