amavis-user April 2014 archive
Main Archive Page > Month Archives  > amavis-user archives
amavis-user: Re: your mail

Re: your mail

From: Alexander Dalloz via amavis-users <amavis-users_at_nospam>
Date: Wed Apr 16 2014 - 17:54:22 GMT
To: amavis-users@amavis.org

Am 16.04.2014 19:33, schrieb Patrick Ben Koetter via amavis-users:
> Alexander,

[ .. ]

>> Perl's Net::Server is a central component as much as I know and takes care
>> for binding to the defined ports. Which part is responsible for the EGID
>> und EUID used by the amavisd-new processes? It looks like there is a main
>> issue. Why else would there be an error
>>
>> Apr 14 17:14:29 ikes19 amavis[4265]: (04265-01) (!)connect to
>> /var/run/klms/rds_av failed, attempt #1: Can't connect to UNIX socket
>> /var/run/klms/rds_av: Permission denied
>> when the amavisd-new daemon runs as amavis:amavis (106:110) and the UNIX
>> permissions for the Kaspersky socket including the complete path are as
>> outlined in the forum post:
>>
>> # ls -ld / /var /var/run /var/run/klms
>> drwxr-xr-x 24 root root 4096 Mar 27 16:24 /
>> drwxr-xr-x 11 root root 4096 Mar 27 16:16 /var
>> lrwxrwxrwx 1 root root 4 Mar 24 16:00 /var/run -> /run
>> drwxrwx--- 2 kluser klusers 1980 Apr 14 18:25 /var/run/klms
>> # ls -al /var/run/klms/rds_av
>> srw-rw---- 1 kluser klusers 0 Apr 14 17:47 /var/run/klms/rds_av
>>
>> # getent group klusers
>> klusers:x:111:kluser,amavis
>>
>> The amavis user part of the klusers group.
>
> counter evidence: Have you tried to give 777 ogu access to the socket all the
> way down just to prove the permissions are causing the problem?

I did that in fact: I do not call this a solution but then amavisd-new
does not fail. It is not a solution as those world permissions are awful
wrong.

>> Regarding the other error situation where the on-demand Kaspersky scanner
>> fails with "Can't connect to facade" seems to originate from the same
>> permissions situation.
>
> If both applications - amavis and kav - fail to connect the same path the
> problem is like not in these applications. The first thing that comes to my
> mind is some third component. But as you've already outlined you don't have
> app-armor in place/production.

I too have no idea which part of the system could interfere. AppArmor
absence has been verified.

I hope the Kaspersky team can find outwhat is going on.

>> # ls -al /var/run/klms/facade
>> srwxr-xr-x 1 kluser klusers 0 Apr 14 17:47 /var/run/klms/facade
>
> Can you strace the Kaspersky scanner?

Well, I could do that in addition. Just expanding the AV call in the
amavisd-new configurtion by a strace statement which will write a log?
It is a client calling a permanently running daemon.

> Have you tried to run amavis at its highest log level? You need an extra disc
> for that... ;)

Highest level is 5, right? I can repeat that, but think I already did so
with no findings.

>> amavisd-new isn't setup to run chrooted, while Postfix is (as in Debian's
>> default configuration).
>
> amavis runs outside Postfix and is not affected by Postfix chroot.

That's my view on this part of the story as well.

> p@rick

Cheers

Alexander