Kopano spamd error - PermissionError: [Errno 1] Operation not permitted

ashceryth

Guys, I think what you did is a workaround. Since you set the sa_group to kopano there is no change when executing chown (https://github.com/Kopano-dev/kopano-core/blob/master/ECtools/spamd/kopano_spamd/__init__.py#L104 line 104 onwards) on the files as they’re already owned by kopano:kopano. So, this way the original problem discussed in this thread isn’t triggered (that’s just what I think). Of course it works the other way round if you add amavis to the kopano group and then run inotify-spamlearn as user amavis. This way the user amavis has read and write permissions on the files as the user is member of the kopano group. Just my two cents.

And please don’t mix up spamd and inotify-spamlearn. These are two different things.

BMWfan

@ashceryth thanks for your opinion. You are right i think. I added kopano as described in my post before in the amavis group but the problem exists still if i configure this sa_group = amavis.
I can execute this manually sudo -H -u kopano chown kopano:amavis /var/lib/kopano/spamd/spam/9DFD4A4E633343C081465B7B8EDBCBE4.eml but the script gives us the following error if it has to execute it triggerd by the mail displacements in Kopano Webapp.

PermissionError: [Errno 1] Operation not permitted: '/var/lib/kopano/spamd/spam/9DFD4A4E633343C081465B7B8EDBCBE4.eml'

BMWfan

@mark-dufour do you need more informations to reproduce this issue?

fbartels

This ultimately seems to be an issue with/experienced through systemd. The permission denied when chown’ing comes from systemd denying it.

We will still need to think about alternative approaches for this.

BMWfan

@fbartels thanks for your answer. Should i open a request anywhere or what are the next steps?

fbartels

@cblaha @ckruijntjens @BMWfan Did some further thinking today and the simplest approach is probably the easiest.

Could you try the following (assuming you need your eml files to be kopano:amavis in the end):

in spamd.cfg
-> set run_as_group to amavis
-> sa_group should then be amavis as well

make sure kopano is member of the amavis group (writing this out i am not 100% this is really a requirement)
make sure that /var/lib/kopano/spamd (recursively) is owned by kopano:amavis

If this works for you as well, then we will remove the sa_group option and its related mechanism from kopano-spamd and adopt documentation accordingly.

cblaha

@fbartels : I will try it tomorrow

cblaha

@fbartels: Sorry, that I am reporting so late. Your solution works perfect for me. Thank you

for me this is also working. Except i am using rspamd so for me the group is _rspamd

This works as expected!

weini

Works for me too!
Many thanks for your support!

pschoond

I had the same problem on CentOS 7.

I think I solved this easily by:

adding the amavis user to the group kopano.
Since amavis/sa-learn is now able to read the files in /var/lib/kopano/spamd/spam, it is no longer necessary to do a chow or chmod in kopano-spamd. So I commented these two lines (106,107) out in /usr/lib/python2.7/site-packages/kopano_spamd/init.py, like this:
#os.chown(emlfilename, uid, gid)
#os.chmod(emlfilename, 0o660)
By increasing the loglevel to Info in /etc/kopano/spamd.cfg I could verify that the results are now as expected in the systemlog:

aug 02 07:33:33 server03.xxxxx.local kopano-spamd[17541]: 2019-08-02 07:33:33,488 - spamd - INFO - Learning message as SPAM, entryid: 0000000000D9DA0165C843EBB498FB6BD1E7C5820100000005000000519FE396E2274687B6E78B016896BC6000000000

I’m not sure though if sa-learn is automatically triggered within kopano-spamd on CentOS.

Paul