Bugzilla Bug 96917

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.