your mail

[Thomas Spuhler via amavis-users]

On Wednesday, April 16, 2014 08:03:51 PM Patrick Ben Koetter via amavis-users wrote:
> * Alexander Dalloz via amavis-users <ad+lists at uni-x.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.
> 
> Agreed, it isn't a solution, but it proves we are looking at the right
> issue. What if you
> 
> sudo -i -u amavis
> 
> and then try to walk the path up to /var/run/klms/$SOCKET?
> 
> Any place you get stuck?
> 
> > >>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.
> 
> Did they provide a reference implementation in an installation instruction?
> 
> > >># 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.
> 
> Whatever brings you closer to the moment where things start to fail.
> 
> > >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.
> 
> Doing again will likely not change the output. ;)
> 
> p at rick

Hmmmm... what distro are you using? If you use Mageia, there is a problem with the permission wehn 
we use clamd. Maybe similar with Kaperski (daemon)
You need to add the kaperski to the amavis group and then change the permission of /run/klms/ so 
amavis can write to it.

-- 
Best regards
Thomas Spuhler

All of my e-mails have a valid digital signature
ID 60114E63
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.amavis.org/pipermail/amavis-users/attachments/20140416/5257ff21/attachment.sig>