Bug 178725

Summary:	clamav-autoupdate issues with email and files
Product:	[Fedora] Fedora	Reporter:	Paul Wouters <paul>
Component:	clamav	Assignee:	Enrico Scholz <rh-bugzilla>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9	CC:	extras-qa, kevin, nsoranzo, rpm
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	0.93-1.fc9	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-05-15 13:25:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul Wouters 2006-01-23 19:50:56 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I noticed two things in clamav-updates

1) It executes a file in /usr/share, while share is defined according to the lsb for "Architecture-independent data", and one should be able to mount it with noexec. This is better put in a crontab entry anyway, instead of being called indirectly through crontab.

2) /etc/cron.d/clamav-update sets MAIL= to root, webmaster, postmaster and clamav,
which generates *four* emails, which is excessive. The clamav-* packages also did not create a user or alias for "clamav", so this generates a bounces on top of the other emails.

3) it takes an effort to enable updating, which i think that if people install clamav-update is what they give "permission" for to do to begin with. I think it should just work istead of having all these manual edits requires before it works.


Version-Release number of selected component (if applicable):
clamav-update-0.88-1.fc4

How reproducible:
Didn't try

Steps to Reproduce:
1. install clamav-* rpms
2. wait for cron to kick in
3.
  

Additional info:

Comment 1 Nicola Soranzo 2006-11-29 12:43:07 UTC

This bug applies also to FC6.

Comment 2 Enrico Scholz 2006-11-29 13:32:19 UTC

1. putting scripts into /usr/share is common practice in Fedora; I did not found
an indication in LSB that /usr/share count be mounted noexec. I do not
understand the comment about the crontab.

2. before adding these recipient, it was complained that nobody would see the
mails because mails to root would go to /dev/null. Or, do you know a better,
universal recipient which would be read on every system?

3. won't change that. It would be a bug when program connects to the internet
without explicit activation.

Comment 3 Nicola Soranzo 2006-11-29 15:24:49 UTC

1. You're right about the noexec option, anyway the FHS (which is mandatory for
LSB) says that /usr/share is for Architecture-indipendent _data_ (see
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA ).

2. If you're a sys admin and configure your /etc/aliases, you surely change root
alias. Otherwise in a standard install webmaster and postmaster are aliased to
root, clamav bounces to root (which in this way receive 4 emails every 20 mins).
In both cases I'd leave only root, as most other cron scripts.

3. That's up to you, but yum-updatesd/puplet don't work like that.

Comment 4 Paul Wouters 2006-11-30 05:55:11 UTC

1) is a real bug with LSB. not enough for me to keep this bug open.
2) anyone not having a root mail alias is choosing to have their mail go to
/dev/null. It surely beats 4 emails and a bounce for everyone. eg let the ones
who break the system on purpose have a problem, not the one who properly
configure their email setup.
3) It's your choice as package maintainer.

If you fix 2, I'd consider my bug report handled

Comment 5 Nicola Soranzo 2008-01-09 11:48:36 UTC

Still applies to Fedora 8.

Comment 6 Nicola Soranzo 2008-03-31 15:51:43 UTC

*** Bug 427103 has been marked as a duplicate of this bug. ***

Comment 7 Bug Zapper 2008-05-14 02:04:38 UTC

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping