Bug 725406

Summary:	clam.log and freshclam.log change owners each time they are rolled
Product:	[Fedora] Fedora EPEL	Reporter:	Virgil Balibanu <virgil.balibanu>
Component:	clamav	Assignee:	Jan-Frode Myklebust <janfrode>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	el5	CC:	janfrode, nathanael, nb, redhat-bugzilla, steve
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-07-25 13:01:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Virgil Balibanu 2011-07-25 12:01:16 UTC

Description of problem:
From time to time the user and group for the files clam.log and
freshclam.log
change from clamav:clamav to clam:clam thou the user is set to clamav in
the
config. This messes up the service because it no longer has acces rights
on the
log files. I believe this happens when the log files rotate.
I'm using CentOS 5.5 and I installed clamav following the steps here:
http://www.linuxmail.info/how-to-install-clam-antivirus-centos-5/

Version-Release number of selected component (if applicable):
0.97

How reproducible:
one a week ussually, when the log rolls.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Jan-Frode Myklebust 2011-07-25 12:58:28 UTC

This is done by /etc/logrotate.d/clamav. If you need to run clamd as another user than "clam", you should also update this logrotate-config to create the logfile as this user.

But running it as the default user "clam" will be better, as you woun't need to edit this logrotate file, and you woun't need to re-redit it after upgrades.

Comment 2 Jan-Frode Myklebust 2011-07-25 12:59:59 UTC

.. and also /etc/logrotate.d/freshclam needs to be updated..

Comment 3 Jan-Frode Myklebust 2011-07-25 13:01:27 UTC

I'm closing this ticket, since I think this is intended behaviour.

Comment 4 Virgil Balibanu 2011-07-25 14:17:13 UTC

thanks