Hi. I've found a couple of upstream bugs in razor-2.72 which are described in detail here: http://article.gmane.org/gmane.mail.spam.razor.user/3659 I'm filing this here because one of the bugs slightly affects the amavisd-new ebuild. For example, lines 156-167 of amavisd-new-2.2.1.ebuild read as follows: razor-admin -create -home=${ROOT}${AMAVIS_ROOT}/.razor sed -i -e "s:debuglevel\([ ]*\)= .:debuglevel\1= 0:g" \ ${ROOT}${AMAVIS_ROOT}/.razor/razor-agent.conf But the razor-agent.conf file will not be created (certainly on a "clean" system) which causes sed to complain about it. As far as I'm aware, razor-check should still function under these circumstances, although I've not put it to the test in the context of amavisd-new. Therefore, I've marked this bug as "minor". But I'm filing this because (1) I think these bugs are worth considering in terms of tracking razor upstream - obviously, the razor-agent.conf file should be created. (2) just in case there are other issues related to this topic. Here's hoping for a better razor release ...
I've just noticed something else: that invocation of razor-admin violates the notion of config file protection too. Try and setup a default /etc/razor/razor-agent.conf file _then_ emerge amavisd-new. razor-admin will be called (with root priveleges) and completely trample over the existing file. It gets worse ... I've found what I think is another bug in razor-2.72 where it writes configuration files under /etc/razor (even though it's told to put them elsewhere). Naturally these files will escape the attention of portage itself and could potentially stomp others. Granted, it will perserve policies already defined in the file but I think this is not really the point. Surely, no ebuild should ever invoke a peripheral tool which has the ability to trample over anything under /etc (especially as root) and bypass portage's config protection? Furthermore, should it be creating files which fall out of the scope of portage's tracking mechanism at all? Should we really be trusting and executing tools like this outside of the context of the sandbox? Here's my follow up which mentions the other bug: http://article.gmane.org/gmane.mail.spam.razor.user/3662
CC'ing myself, as one of the maintainers. Could you guys inform jpr+gentoo@darkridge.com,mail@vipul.net in the future for bugs against razor? That way we could address them more quickly.
Jordan are you planning to release an fixed version? If that is the case I suggest we wait for that otherwise we can rip out the razor integration from amavisd-new for now.
I should have a release candidate out in a few minutes.
For reference, Richard is also one of the maintainers. We (Cloudmark) got a few last minute bug reports this morning which we are addressing now, and our intention is to get a full release out somtime over the weekend. So from a planning perspective, expect by Monday to have something new to integrate.
razor-agents 2.74 was just released, fixing this and several other bugs. You can find the latest release on the razor website, http://razor.sf.net/.
*** This bug has been marked as a duplicate of 96776 ***
sorry I did not catch the full bug header these are two seperate bugs sorry once again stupid bot translated the Summary wrong I will fix it later.
2.74 (fresh in portage) doesn't put anything into /etc/razor on my system during amavisd-new emerge, everything goes nicely into /var/amavis/.razor. These files still go unnoticed by portage, I'll try moving the razor bit to src_install() sometimes later today, so everything happens neatly still inside the sandbox. Cloudmark guys: thanks for fixing mentioned bugs from 2.72
Andrej, any reason to keep this one open when stabilization is on bug #96776?
I'd like to keep this one until I get around to do what I mentioned in comment #9. It's more of amavisd-new bug now, I guess, and not security-related anymore. I'm changing the summary, feel free to trim down CC as you deem fit.
Re comment #9: yes, all of the bugs which I noticed before appear to have been resolved by Richard, Jordan et al (thanks guys :) But, as the rather more sensible summary for this bug now suggests, there is still the matter of portage managed config file protection and whether or not any files can be clobbered with regard to the way in which amavisd-new interacts with razor-agent. I believe I know of a specific scenario where this can actually happen still but I need to do a litte more testing and get some sleep first - not necessarily in that order! I'll post back regarding that in more detail soon(ish) if my concern turns out to be well founded.
Ok, this solution is not necessarily clean, but I've done this in src_install(): if $(has_version mail-filter/razor) ; then if [ ! -f ${AMAVIS_ROOT}/.razor/razor-agent.conf ] ; then einfo "Setting up initial razor config files..." razor-admin -create -home=${D}/${AMAVIS_ROOT}/.razor sed -i -e "s:debuglevel\([ ]*\)= .:debuglevel\1= 0:g" \ ${D}/${AMAVIS_ROOT}/.razor/razor-agent.conf else einfo "Copying existing razor config files..." insinto ${AMAVIS_ROOT}/.razor doins ${AMAVIS_ROOT}/.razor/razor-agent.conf \ ${AMAVIS_ROOT}/.razor/server* fi fi The logic is, that if an existing amavisd-new razor setup is found in live filesystem, razor-agent.conf and server* files are copied into Portage image, otherwise a new config is generated inside the image. This should preserve existing razor config without bringing too many files into portage. I'm going to commit newly released 2.3.2 with this bit, and if it works well for people (no bugreports), I'll backport it to 2.3.1 before bumping it to stable x86. Any suggestions?
On second thought, it's probably better to copy *.lst and *.conf (from /var/amavis/.razor), in case upstream changes the filenames in the future. I've committed the change.
For the record, we haven't changed the filenames since releasing version 2, and we have no plans to do so in the future.
This seems to work. I'm closing the bug as FIXED. Thanks everyone.
