I wanted to try app-antivirus/clamav with clamonacc USE flag for on-access file scanning. Starting the RC script seems to work: $ sudo /etc/init.d/clamonacc start * Starting clamonacc ... [ ok ] But when I noticed trying to access an EICAR test file doesn't trigger any issue, I checked it and so clamonacc was not actually running. Trying to run from the command line the same command the RC script runs shows that clamonacc indeed fails to start: $ sudo /usr/sbin/clamonacc --foreground ERROR: Clamonacc: at least one of OnAccessExcludeUID, OnAccessExcludeUname, or OnAccessExcludeRootUID must be specified ... it is reccomended you exclude the clamd instance UID or uname to prevent infinite event scanning loops The command exited with a failure status, but the RC script is not able to notice it: $ echo $? 2 There is a line for OnAccessExcludeUname in /etc/clamd.conf, but it's commented: #OnAccessExcludeUname clamav Uncommenting it allows clamonacc to start. Maybe the ebuild should uncomment it? At least when clamonacc is enabled. Although this would allow clamonacc to start, it will still do nothing because there are no paths configured by default to be scanned on access: $ sudo /usr/sbin/clamonacc --foreground ERROR: ClamInotif: Please specify at least one path with OnAccessIncludePath But I'm not so sure it's also the task of the ebuild to configure that. Maybe just a pkg_postinst einfo? Note that the correct option is not necessarily OnAccessIncludePath as stated in the message and it could be OnAccessMountPath if DDD is enabled: https://www.clamav.net/documents/on-access-scanning Even after fixing all that, clamonacc functionality is limited, but I think this is more an upstream issue. clamonacc uses clamd to scan the files, which by default runs as clamav user, so it will fail to scan any file clamav user doesn't have access to. It would be enough for a virus with setting the permissions of its payload file to 600 to bypass on-access scan. That could be worked around by making clamd run as root, but that would require setting OnAccessExcludeUname to root, which would mean files accessed by root wouldn't be scanned, which is also a security issue. I guess a better workaround could be setting a recursive ACL for clamav user to be able to access any file, but that sounds a bit like cracking nuts with a sledgehammer.
(In reply to Jesús P Rey (Chuso) from comment #0) > > The command exited with a failure status, but the RC script is not able to > notice it: > > $ echo $? > 2 > This is probably a real bug that we could fix, but upstream has rejected the patches for OpenRC and is going to rewrite the entire build system in the next release (and require Rust...), so I'm personally not very inclined to waste any more time trying to improve things for them. While not directly responsible, the OpenRC script has to jump through hoops because of this upstream issue: https://bugzilla.clamav.net/show_bug.cgi?id=12595 > But I'm not so sure it's also the task of the ebuild to configure that. > Maybe just a pkg_postinst einfo? Yeah, I agree that it sucks, but there's really no way around it: you have to tell clamonacc what you want it to scan. Security concerns (and not wanting to crash the system) make it impossible for us to guess at these settings. An einfo is a good idea, or it might be better if the service script reported the problem and suggested a solution because that's harder to overlook. > Even after fixing all that, clamonacc functionality is limited, but I think > this is more an upstream issue... You're absolutely right, but there's already an "easy" solution to this problem. If you run clamd on a local socket and if you start clamonacc with the --fdpass flag, then clamonacc will pass a file descriptor to clamd rather than a path name, and that allows clamd to read it without any special privileges. Where this goes wrong is that "--fdpass" is a command-line flag for clamonacc, but the socket is configured somewhere else, in clamd.conf. So we can't decide in the OpenRC script whether or not we should use --fdpass. IIRC there's an upstream bug about this somewhere. (I wonder if we can enable this unconditionally even if the user has a TCP/IP socket configured.) Clamonacc is still pretty new and unpolished in my opinion. People are just starting to use it and report all the bugs that arise. A lot of these problems will sort themselves out as time goes on.
I agree that an einfo in pkg_postinst that clamonacc requires further configuration would definitely be a good idea.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b99345bb35e9a6a208a3aa3cd6660b4d606cdb3 commit 7b99345bb35e9a6a208a3aa3cd6660b4d606cdb3 Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-06-24 10:24:55 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-06-24 11:04:15 +0000 app-antivirus/clamav: package maintenance revbump 1.3.1 with the following fixes: - add postinst message for 'clamonacc' - fix x32 builds - fix PID paths - drop py310; add py313 Bug: https://github.com/Cisco-Talos/clamav/issues/1076 Bug: https://bugs.gentoo.org/921088 Bug: https://bugs.gentoo.org/916147 Bug: https://bugs.gentoo.org/787233 Closes: https://bugs.gentoo.org/927214 Signed-off-by: Matt Jolly <kangie@gentoo.org> app-antivirus/clamav/clamav-1.3.1-r1.ebuild | 409 +++++++++++++++++++++ .../clamav/files/clamav-1.3.1-onenote-rs.patch | 30 ++ 2 files changed, 439 insertions(+)
The init.d file for clamonacc is missing a way to add extra command_args from a conf.d file, so the "correct" way one would add the "--fdpass" argument to clamonacc is not currently possible.
