docker-mailserver: ClamAV - permission denied on amavis tmp dir

Context

Hi, I have the same problem like the closed issue no #1353 I’ve installed the mailserver on an kubernetes cluster and want to use the integrated ClamAV service for scanning. with (ENABLE_CLAMAV=1).

What is affected by this bug?

The mails will not be scanned by ClamAV. It generate an permission denied error log message

When does this occur?

on running the application.

How do we replicate the issue?

Install (like wiki)
send a mail from existing user to himself
see logs

Actual Behavior

On an incoming email, this is writes in the logs:

run_av (ClamAV-clamd) FAILED - unexpected , output=“/var/lib/amavis/tmp/amavis-20201117T091752-00289-lTvNEEz7/parts: lstat() failed: Permission denied. ERROR\n” amavis[289]: (00289-01) (!)ClamAV-clamd av-scanner FAILED: CODE(0x55dda70f2a50) unexpected , output=“/var/lib/amavis/tmp/amavis-20201117T091752-00289-lTvNEEz7/parts: lstat() failed: Permission denied. ERROR\n” at (eval 98) line 951. amavis[289]: (00289-01) (!)WARN: all primary virus scanners failed, considering backups

Expected behavior (i.e. solution)

ClamAV should be able to analyze the emails without permission problems

Your Environment

Amount of RAM available: 8GB
Mailserver version used: latest
Docker version used: 19.03.13
kubernetes version used: v1.19.3
Environment settings relevant to the config:

System

A kubernetes Cluster with an NFS pv

System configuration

pv.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mail-storage
  labels:
    type: local
  namespace: mailserver
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: xxx.xxx.xxx.xxx
    path: "/srv/nfs/kubedata/smtp/mail-storage"

pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mail-storage-claim
  namespace: mailserver
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 500Mi

configmap.yaml

data:
  ONE_DIR: "1"

deployment.yaml

          - name: data
            mountPath: /var/mail
            subPath: data
          - name: data
            mountPath: /var/mail-state
            subPath: state
          - name: data
            mountPath: /var/log/mail
            subPath: log

        - name: data
          persistentVolumeClaim:
            claimName: mail-storage-claim

NFS

And when I do ls -aln /var/lib/amavis/tmp/, I get this :

drwxrwx— 4 112 114 4096 Nov 17 10:21 . drwxr-x— 8 112 114 4096 Nov 17 10:19 … drwxr-x— 3 112 114 4096 Nov 17 10:20 amavis-20201117T092012-00283-H7KnOmih drwxr-x— 3 112 114 4096 Nov 17 10:21 amavis-20201117T092102-00282-5WnlwIhO

and on the NFS server i do ls -aln /srv/nfs/kubedata/smtp/mail-storage/state/lib-amavis/tmp, I get this:

drwxrwx— 4 112 114 4096 Nov 17 10:21 . drwxr-x— 8 112 114 4096 Nov 17 10:19 … drwxr-x— 3 112 114 4096 Nov 17 10:20 amavis-20201117T092012-00283-H7KnOmih drwxr-x— 3 112 114 4096 Nov 17 10:21 amavis-20201117T092102-00282-5WnlwIhO

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 21 (12 by maintainers)

Most upvoted comments

Just an fyi, a very late one, but this seems to be due to amavis rather than any config setting in docker-mailserver

root@mail:/# grep -n -A 10 -B 10 'chmod(0750,$dname)'  /usr/sbin/amavisd-new
7646-    }
7647-  }
7648-  if (!defined $dname) {
7649-    # invent a name of a temporary directory for this child
7650-    my $dirtemplate = sprintf("amavis-%s-%05d-XXXXXXXX",
7651-                              iso8601_timestamp(time,1), $my_pid);
7652-    $dname = File::Temp::tempdir($dirtemplate, DIR => $TEMPBASE);
7653-    defined $dname && $dname ne ''
7654-      or die "Can't create a temporary directory $TEMPBASE/$dirtemplate: $!";
7655-    do_log(4,"TempDir::prepare_dir: created directory %s", $dname);
7656:    chmod(0750,$dname)
7657-      or die "Can't change protection on directory $dname: $!";
7658-    @stat_list = lstat($dname);
7659-    @stat_list or die "Failed to access directory $dname: $!";
7660-    $self->{tempdir_path} = $dname;
7661-    ($self->{tempdir_dev}, $self->{tempdir_ino}) = @stat_list;
7662-    $self->{empty} = 1; add_entropy($dname, @stat_list);
7663-    section_time('mkdir tempdir');
7664-  }
7665-  $errn = @stat_list ? 0 : 0+$!;
7666-  if ($errn != 0) {

you can see here, line 7656, the permissions are set to 0750, no write permissions for the group. User clamav is in the amavis group, but without correct permissions this makes no difference

as a temporary fix I suggest a config/user-patches.sh like this

#!/bin/bash
# patch amavis-new to set group permissions on temporary directories
# first backup file before changes
cp /usr/sbin/amavisd-new /usr/sbin/amavisd-new.bak
# fix any previously incorrectly applied permissions
chmod -R g+w /var/lib/amavis/tmp/
# correct the setting of perms on the tmp/amavis-*/ directories
sed -i 's/chmod(0750,$dname)/chmod(0770,$dname)/' /usr/sbin/amavisd-new
# correct the setting of perms on the tmp/amavis-*/parts(/subdir) directories
sed -i -E 's/(mkdir\("\$tempdir\/parts)(\/\w*)?(\",[ ]?)(0750)(\))/\1\2\30770\5/g' /usr/sbin/amavisd-new

[edit] attached wrong version of user-patches.sh, didn’t fix tmp/subdirs

allFunAndGames on Mar 2, 2022

If you have a test cluster I would suggest trying one thing at a time. Specifically get rid of the NFS server and use a simpler mount option. If that works you know it is NFS-related (which I suspect).

EDIT: another possibility is that Amavis crashes due to out of memory. With K8s there is normally no swap, so if memory is scarce you will crash. That can look like this. Have you really allocated 8G to this specific deployment? That should be more than enough, just wondering? Is it the resource limit or resource requirement?

erik-wramner on Nov 20, 2020