Summary: | app-antivirus/clamav: clamonacc doesn't work out of the box | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jesús P Rey (Chuso) <gentoo> |
Component: | Current packages | Assignee: | Antivirus Team <antivirus> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | ab4bd, genzilla, jstein, kangie, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jesús P Rey (Chuso)
2021-04-30 20:52:31 UTC
(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. |