With the wholesale change of the rc script for clamd at this version, it makes a blunder by assuming that the ownership of /var/clamav should be the default. This code is the culprit: start_pre() { # This exists to support the (disabled) default LocalSocket setting # within clamd.conf. The "clamav" user and group agree with the # (disabled) default "User" and "LocalSocketGroup" settings in # clamd.conf. And everything here agrees with the # clamav-daemon.socket systemd service. # # Creating this directory is harmless even when a local socket is # not used. checkpath --directory \ --mode 0755 \ --owner clamav:clamav \ "/run/clamav" } If you run clamd as any other use (e.g. amavis in my case), you get the following error on startup: ERROR: LOCAL: Socket file /run/clamav/clamd.sock could not be bound: Permission denied This script should honour the setting in /etc/clamd.conf for: User <username> LocalSocketGroup <groupname>
Well, you are right of course. There are a few places where I was forced to state "this must agree with what's in your configuration file," and that's not a very robust approach. The fundamental problem is that the service manager (OpenRC, systemd,...) has no idea what's in your configuration file. In a perfect world, all of the parameters that need to be known by the service manager would be passed (at least optionally) on the command-line rather than placed in the configuration file. In the long term, that may happen upstream, but it will take some time. Until then, everything must be made to agree manually or at build time. Users of systemd face the same problem. Even the upstream systemd scripts assume the user/group is "clamav", for example in https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.104/clamd/clamav-daemon.socket.in But let me stop making excuses and help you fix your problem. While I admit the design flaw in the OpenRC script, there's almost certainly a better solution for what you're trying to do than to run clamd as the amavis user. Presumably you're running clamav as the "amavis" user because, otherwise, it can't read the mail files that belong to amavis? There is an option to clamdscan that works around that problem. In your amavisd.conf, replace whatever @av_scanners line you have with # Use clamdscan with the --fdpass option so that the "clamav" user doesn't # need to be able to read amavis's private working directory. @av_scanners = ( ['ClamAV-clamdscan', 'clamdscan', "--fdpass --stdout --no-summary {}", [0], qr/:.*\sFOUND$/m, qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ], ); That should allow amavisd-new to run as amavis and clamd to run as clamav, with everything working out of the box. That @av_scanners line is now the default recommendation in the upstream amavis project for this very reason.
I am running mail-filter/amavisd-new-2.12.0-r4, which is the only version available in the Gentoo repository. There is no reference to --fdpass in the configuration file, I conclude because it's not supported at this version. Also, the proto entry that matches your example (minus --fdpass) is under @av_scanners_backup = ( in the package configuration file. Under av_scanners I have this: @av_scanners = ( ['ClamAV-clamd', \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"], qr/\bOK$/, qr/\bFOUND$/, qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ], # ### http://www.clamav.net/ # ['ClamAV-clamd', # \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.sock"], # qr/\bOK$/m, qr/\bFOUND$/m, # qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ], # # NOTE: run clamd under the same user as amavisd - or run it under its own # # uid such as clamav, add user clamav to the amavis group, and then add # # AllowSupplementaryGroups to clamd.conf; # # NOTE: match socket name (LocalSocket) in clamav.conf to the socket name in # # this entry; when running chrooted one may prefer a socket under $MYHOME. (I have /var/run -> /run via symbolic link) I ruled out the "AllowSupplementaryGroups" approach since that parameter is not present in /etc/clamd.conf Your example does not use a socket, hence I am sceptical that it will use the clamd service. Use of the socket matches what amavis is expecting, at least that's my take. I got the service running "out of the box" as you put it by changing the socket location to somewhere clamd would not touch without specific parameter settings, and that works. However - this is a bug in clamd. One cannot start it if one uses the /run/clamav directory for it's socket, and you run it under a different user to clamav - both settings that are allowed in /etc/clamd.conf .
(In reply to Ian Pickworth from comment #2) > I am running mail-filter/amavisd-new-2.12.0-r4, which is the only version > available in the Gentoo repository. > > There is no reference to --fdpass in the configuration file, I conclude > because it's not supported at this version. This has changed since the last release of amavisd-new: https://gitlab.com/amavis/amavis/-/blob/master/conf/amavisd.conf#L362 The --fdpass flag is an argument to clamdscan, and you can check yourself that it works on your machine. > I ruled out the "AllowSupplementaryGroups" approach since that parameter is > not present in /etc/clamd.conf Yes, that is also outdated advice. > Your example does not use a socket, hence I am sceptical that it will use > the clamd service. Use of the socket matches what amavis is expecting, at > least that's my take. It does. The clamdscan program reads /etc/clamd.conf to determine the location of the socket before connecting to it, which is another benefit of clamdscan (the reduced duplication). To convince yourself that it uses the clamd service, run it twice. It will be fast. > However - this is a bug in clamd. One cannot start it if one uses the > /run/clamav directory for it's socket, and you run it under a different user > to clamav - both settings that are allowed in /etc/clamd.conf . I agree, but there will never be a way to parse configuration files safely from shell script, so the ultimate solution to that problem will be to remove a few things from the config file and place them into the build scripts and/or CLI flags. In the meantime, it's not so big a deal as long as it doesn't break any configurations that can't be done in a better way. I don't want to sound obnoxious, but using "clamdscan --fdpass" is just a much better way to achieve what you're doing, so the severity of the bug is lessened IMO.
Thanks for the explanation. I've studied the configurations as you suggested, and changed my setup to use clamdscan, also achieving the separation of users as you suggested. Since this appears to be a small improvement in security, I suggest a resolution to this defect as follows: - Add additional notes to the ebuild that draw attention to strong recommendation to run clamd and amavis as separate users, using the clamdscan configuration. I think this is as big a deal as the change to having to start freshclam separately, so the precedent for a build note is there. - Patch the upstream /etc/clamd.conf file to add a comment at the user entry to draw attention to the advice as above. - At the point before you make this approach stable - issue a news article that explains the change, its advantages, and the fact that people using the previous socket approach will have to make a change. People running live email services need advanced warning and a lot of reassurance before undertaking a configuration change, so the above will help I believe.
Somebody else seems to have hit this on the forums: https://forums.gentoo.org/viewtopic-p-8638066.html#8638066.
Michael, are there any docs changes that can be made (or have been) as a result of this ticket? Once that's done I think we can close this one off.
