Sven, I think your points in reply to Bernd are spot-on. I really don't have much to add except to say that it's fairly common for Perl daemons to start as root and then daemonize under a user account, at least from what I've seen. The issue with SA using root/.spamassassin/user_prefs at startup is a minor inconvenience at worst, but we're looking into eliminating that with the next release.
To use site-wide Bayes/whitelist you absolutely need to put the DBs in a shared location (this is not specific to spampd). Cheers, -Max At 12/22/2005 07:03 PM +0100, Sven Mueller wrote: >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]
