Red Hat Bugzilla – Bug 1284253
permissions on /var/run/clamd.scan directory should be 755 not 710
Last modified: 2018-02-02 15:21:39 EST
Description of problem: Freshclam does not provide a systemctl service file. Additionally, the distributed clamd@.service and firstname.lastname@example.org file structure does not seem to make sense. And there is a permission issue with the directory containing the socket file which causes failures.
To workaround, create a /usr/lib/systemd/system/clam-freshclam.service file:
Description = freshclam scanner
After = network.target
Type = forking
ExecStart = /usr/bin/freshclam -d -c 4
Restart = on-failure
PrivateTmp = true
There are two distributed clamd@*.service files distrbuted, clamd@.service and email@example.com. clamd@.service is not a valid unit name.
firstname.lastname@example.org seems to simply include clamd@.service and add an [Install] section.
On my system I enable and start email@example.com.
Lastly, there is a directory permissions issue if the clamd socket file is created at /var/run/clamd.scan/clamd.sock as specified by /etc/clamd.d/scan.conf. When /var/run/clamd.scan is created is it not world readable and executable by default. This causes permission related issues until a chmod 755 /var/run/clamd.scan is run.
Please let me know if I can supply additional data.
Is the cronjob shipped by default not good enough? And if so, why?
@Robert...for some reason my database was not updating and I overlooked the cronjob. I will disable the freshclam systemd process, verify the cronjob and withdraw that part of this report for the time being.
Any thoughts on the structure of the clamd@scan and clamd@ service files and including setting the directory permission for the socket in the systemd file?
Suggested resolution for the permissions on /var/run/clamd.scan.
/etc/tmpfiles.d/clamd.scan.conf currently contains:
d /var/run/clamd.scan 0710 clamscan clamscan
This should be changed to:
d /var/run/clamd.scan 0755 clamscan clamscan
Updated title to reflect current outstanding issue.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.