Bernd Zeimetz wrote on 20/12/2005 05:07: Maxim: I would be interested to hear any idea you might have about these issues.
> 2. spamassassin/autolearn uses /root/.spamassassin > > After checking the output of spampd in the emails I've seen an > autolearn=failed entry from spamassassin. Starting spampd in debugging > mode showed, that spampd's spammassassin tries to put it's stuff into > /root/.spamassassin/: > [28638] dbg: config: using "/root/.spamassassin/user_prefs" for user > prefs file If you want to use auto-learn (or auto-whitelist for that matter), you will have to configure spamassassin in a way that it uses some other location. However, since this has to be configured in the spamassassin configs, there is nothing I could do about this. Regarding the matter of dropping privileges: The way spampd works, it first reads the spamassassin configs, then uses libnet-server-perl (in its Net::Server::PreForkSimple incarnation) to start a server process (which drops privileges after binding to the configured port). There are basically two options: 1) Only read spamassassin configs after forking This looses most of the performance advantage of running a server process in the first place. And it would require a rewrite of major parts of spampd. 2) Drop privileges outside Net::Server::PreForkSimple. This looses the ability to bind to low ports (<1024), which is a feature many people use (to have spampd run in front of their MTA). Both options are unusable in my opinion. The first is simple to big of a task for this little benefit, the second is a no-no because it would break existing (and working) installations. Also, this certainly isn't any security issue, since the accesses you talk about are done before any user generated input is accepted (i.e. before spampd binds to a port) or are tried after privileges have been dropped. > This works while starting the daemon - seems it's still running as root > at this time, but as soon as it has given up root rights and it's > running as spampd it should be unable to access /root/.spamassassin, at > least on a well configured system. As said, these accesses are done by spamassassin code (and are to be configured/disabled in the spamassassin config). For centralized usage of spamassasssin (like with spampd), I would suggest configuring spamassassin to use an SQL database (how to do this is documented in /usr/share/docs/spamassassin/sql) for bayes and autowhitelist data. > This bug is a bit critical imho, such a daemon should not even try to > access stuff in /root. While this is probably true, there is nothing I could do about that as this is what spamassassin (not spampd) has been configured to do. > Unfortunately I can't come up with a path for this - my knowledge of > perl is much much too minimal. Well, I would certainly love to see a clean solution for this, but I can't come up with one. cu, sven PS: Maxim: libnet-server-perl aka Net::Server changed it's log() behaviour in 0.89 to "fix" the security issues this function had. Their fix is to not allow format strings anymore as the second parameter. I'm working on a fix for this which remains compatible (and secure) with earlier versions of Net::Server. I will let you know as soon as I worked something out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
