rootless docker issues with on access scanning (eset_rtp) on RedHat EL 8.5

[mensch 0]

Hello,

we have a RedHat EL 8.5 server running containers in rootless docker mode. 
If On access Scanning is enabled it slows down the containers a lot AND we see the following eset_rtp messages in /var/log/messages:

Apr 14 09:27:03 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/passwd, size: 1225, event: OPEN, command: runc:[2:INIT], pid: 82794
Apr 14 09:27:13 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/group, size: 715, event: OPEN, command: runc:[2:INIT], pid: 82794
Apr 14 09:27:24 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/group, size: 715, event: OPEN, command: runc:[2:INIT], pid: 82794
Apr 14 09:27:34 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: docker-entrypoi, pid: 82839
Apr 14 09:27:34 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: docker-entrypoi, pid: 82838
Apr 14 09:27:44 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh, size: 1961, event: OPEN, command: 10-listen-on-ip, pid: 82847
Apr 14 09:27:54 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 10-listen-on-ip, pid: 82850
Apr 14 09:28:04 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /docker-entrypoint.d/20-envsubst-on-templates.sh, size: 1037, event: OPEN, command: 20-envsubst-on-, pid: 82855
Apr 14 09:28:15 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 20-envsubst-on-, pid: 82865
Apr 14 09:28:25 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 20-envsubst-on-, pid: 82875
Apr 14 09:28:25 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 20-envsubst-on-, pid: 82874
Apr 14 09:28:35 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /docker-entrypoint.d/30-tune-worker-processes.sh, size: 4613, event: OPEN, command: 30-tune-worker-, pid: 82878
Apr 14 09:28:45 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 30-tune-worker-, pid: 82889
Apr 14 09:28:56 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /docker-entrypoint.sh, size: 1202, event: OPEN, command: docker-entrypoi, pid: 82794
Apr 14 09:29:06 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/passwd, size: 1225, event: OPEN, command: nginx, pid: 82794
Apr 14 09:29:16 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/group, size: 715, event: OPEN, command: nginx, pid: 82794
Apr 14 09:29:26 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/group, size: 715, event: OPEN, command: nginx, pid: 82932

The commands AND paths mentioned in the eset_rtp logs above ARE mostly inside the container. For example: "nginx" is running in the container.

Kernel version:

[mch@vm00947 ~]$ uname -a
Linux vm00947.ict-beheer.local 4.18.0-348.20.1.el8_5.x86_64 #1 SMP Tue Mar 8 12:56:54 EST 2022 x86_64 x86_64 x86_64 GNU/Linux

Eset version:

[mch@vm00947 ~]$ rpm -qa |grep efs
efs-9.0.174.0-1.x86_64

Docker version:

[mch@vm00947 ~]$ rpm -qa |grep docker
docker-ce-cli-20.10.14-3.el8.x86_64
docker-ce-20.10.14-3.el8.x86_64
docker-scan-plugin-0.17.0-3.el8.x86_64
docker-ce-rootless-extras-20.10.14-3.el8.x86_64

Docker info:

[mch@vm00947 ~]$ docker ps
CONTAINER ID   IMAGE              COMMAND                  CREATED        STATUS         PORTS                                     NAMES
73c8d12b2c2e   nginxdemos/hello   "/docker-entrypoint.…"   42 hours ago   Up 9 minutes   0.0.0.0:49153->80/tcp, :::49153->80/tcp   relaxed_ride


[mch@vm00947 ~]$ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.1-docker)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 20.10.14
 Storage Driver: fuse-overlayfs
 Logging Driver: json-file
 Cgroup Driver: none
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  rootless
 Kernel Version: 4.18.0-348.20.1.el8_5.x86_64
 Operating System: Red Hat Enterprise Linux 8.5 (Ootpa)
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 808.6MiB
 Name: vm00947.ict-beheer.local
 ID: 3KQF:IYRP:ZPZZ:XBJ3:HFBC:3KG5:SGL5:IU6Z:HXTN:WWWR:3QEL:UEAZ
 Docker Root Dir: /home/mch@XXXXXXXXXXXXXXX/.local/share/docker
 Debug Mode: false
 HTTP Proxy: hxxp://XXXXXXXXXXXX:3128
 HTTPS Proxy: hxxp://XXXXXXXXXXXX:3128
 No Proxy: localhost,127.0.0.1
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: Running in rootless-mode without cgroups. To enable cgroups in rootless-mode, you need to boot the system in cgroup v2 mode.
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

 

[mskb 0]

We have faced similar problem too.
Did you find any solution about this problem？

Now, we have contacted to ESET support, but not found any solution yet.

[mensch 0]

@mskb:  No, we don't have a solution. I hope ESET can do something about it. We worked around the problem by disabling realtime scanning. Instead that we scheduled a nightly full scan.

 

 

[mskb 0]

@mensch

Thank you for your reply.

We didn't had get any solutions from ESET support.
Eventually, we had checked log(/var/log/messages) and processes(ps -ef) then added to exclude lists one by one until meessages about waiting (kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout) had not occured.

 

[mskb 0]

@mensch
FYI
The latest efs version 9.0.461.0 seems to have improved this issue.