Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1820395
Summary: | Clamav OnAccessScanning disabled | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Joshua Grove <jgrove> |
Component: | clamav | Assignee: | Robert Scheck <redhat-bugzilla> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel7 | CC: | anon.amish, bennie.joubert, ecottom, janfrode, jblaine, j, lee.jnk, ondrejj, orion, redhat-bugzilla, rh-bugzilla, sergio, steve |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | clamav-0.102.3-1.el8 clamav-0.102.3-1.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-05-30 00:40:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Joshua Grove
2020-04-03 00:33:04 UTC
Any ClamAV from 0.102.0 onward requires libcurl 7.45+. That libcurl is not in RHEL 7. A Red Hat support case I opened weeks ago resulted in an answer of (not a direct quote): "upgrade to RHEL 8, sorry, we're not updating libcurl in RHEL 7." So, given that, the next best solution is for the ClamAV EPEL package maintainer to build 0.102.x with a modern static version of libcurl.a See https://bugzilla.redhat.com/show_bug.cgi?id=1757955 where the suggestion to link a static version of libcurl into ClamAV packages was spelled out already and seemingly ignored(?). The ClamAV developers have made their stance on this very well known in many 2020 mailing list posts: that this is a distro problem, not a ClamAV problem, and they won't hear otherwise and don't care that their newer version doesn't work on RHEL 7 (!!!) Here is an untested attempt at patching clamav to build with libcurl 7.29.0 using your suggestion Jeff: https://src.fedoraproject.org/rpms/clamav/pull-request/13 scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=43925554 Please test and give feeback. LGTM Thank, Orion. An additional systemd unit file will be needed for clamonacc which needs to run alongside clamd for OnAccess scanning. FWIW, the unit file packaged for Ubuntu 18 reads as follows and it worked fine[1] on my test host with a build from your src.rpm [Unit] Description=Clam AntiVirus userspace daemon for OnAccess Scanning Documentation=man:clamd(8) man:clamd.conf(5) https://www.clamav.net/documents/ # Check for database existence ConditionPathExistsGlob=/var/lib/clamav/main.{c[vl]d,inc} ConditionPathExistsGlob=/var/lib/clamav/daily.{c[vl]d,inc} [Service] ExecStart=/usr/bin/clamonacc --foreground # Reload the database ExecReload=/bin/kill -USR2 $MAINPID StandardOutput=syslog TimeoutStartSec=420 [Install] WantedBy=multi-user.target FOOTNOTES: 1. [m26560@ipac-el7-tplt ~]$ sudo systemctl start clamd@scan [m26560@ipac-el7-tplt ~]$ sudo systemctl start clamonacc [m26560@ipac-el7-tplt ~]$ ps -ef | grep clam root 20460 1 0 13:09 ? 00:00:00 /usr/sbin/clamd -c /etc/clamd.d/scan.conf root 21727 1 1 13:26 ? 00:00:00 /usr/bin/clamonacc --foreground Apr 30 13:26:36 ipac-el7-tplt.mitre.org systemd: Started Clam AntiVirus userspace daemon for OnAccess Scanning. Apr 30 13:26:36 ipac-el7-tplt.mitre.org clamonacc: ClamInotif: watching '/home' (and all sub-directories) [m26560@ipac-el7-tplt ~]$ cat /home/eicar.txt cat: /home/eicar.txt: Operation not permitted [m26560@ipac-el7-tplt ~]$ Thanks for that. I've updated the PR: - Move /etc/clamd.d/scan.conf to clamav-filesystem - Add clamonacc.service So, this makes a change which I think is warranted: moving /etc/clamd.d/scan.conf to clamav-filesystem. This doesn't strictly make it a filesystem package, but it seems to make the most sense. That file is shared by clamd (@scan service), clamdscan, and clamonacc. I've also tweaked the clamonacc.service file a bit since it seems like it was a bit too much of a direct copy of the clamd.service file. Hopefully simple-koji-ci does another build, but I've also started: https://koji.fedoraproject.org/koji/taskinfo?taskID=43956915 Orion, I'm not seeing a clamonacc.service included in the clamd RPM from the new build you referenced (https://koji.fedoraproject.org/koji/taskinfo?taskID=43956915). If I understand you right, above, I should be. [m26560@ipac-el7-tplt ~]$ sha256sum clamd-0.102.2-7.el7.x86_64.rpm 8950c16a645a80ba6d2085fcd8000fa62584d449106dda60da76f52de400b9f8 clamd-0.102.2-7.el7.x86_64.rpm [m26560@ipac-el7-tplt ~]$ rpm -qlp clamd-0.102.2-7.el7.x86_64.rpm /run/clamd.scan /run/clamd.scan/clamd.sock /usr/lib/systemd/system/clamd@.service /usr/lib/tmpfiles.d/clamd.scan.conf /usr/sbin/clamd /usr/share/doc/clamd-0.102.2 /usr/share/doc/clamd-0.102.2/README /usr/share/doc/clamd-0.102.2/clamd.conf /usr/share/doc/clamd-0.102.2/clamd.logrotate /usr/share/man/man5/clamd.conf.5.gz /usr/share/man/man8/clamd.8.gz [m26560@ipac-el7-tplt ~]$ I messed this a little I suggest that in https://src.fedoraproject.org/rpms/clamav/pull-request/15 what is your opinion ? We run clamd + clamonacc on every host where we run ClamAV and don't allow talking to clamd from anything but localhost, so it ultimately won't matter to us where the files land in the RPMs. But if I had to give my opinion, I think it makes sense to have scan.conf in "clamav-filesystem" and clamonacc in "clamav". I think the issue with the clamonacc.service file having a dep on clamav-daemon.service is tricky to solve in a way that matches various orgs ways of using things. No opinion on that part. The dep there won't affect _us_ (see 1st sentence). I hope everyone's doing well, wherever you all are. Any further thoughts on the above and release timeframe? FEDORA-EPEL-2020-6d1d2497d0 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6d1d2497d0 FEDORA-EPEL-2020-2692293800 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2692293800 FEDORA-EPEL-2020-2692293800 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2692293800 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-6d1d2497d0 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6d1d2497d0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-765ceaa306 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-765ceaa306 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-235a51a239 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-235a51a239 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-765ceaa306 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2020-235a51a239 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report. |