clamd handicraft work

Enrico Scholz enrico.scholz at informatik.tu-chemnitz.de
Tue Jul 19 22:11:59 UTC 2005


smooge at gmail.com ("Stephen J. Smoogen") writes:

> I think the main problem I see with these clamav conversations is a
> lack of understanding between the packagers and the people using it. 
> It might help if the design decisions need to be better communicated
> than telling someone to go to bugzilla.us to find out why things were
> done this way. Adding a %doc Fedora-Packaging-Design-Faq.txt would be
> useful.

Ok; I will work on it.


> [It is useful to have this in the package because there are
> too many situations where you have to troubleshoot a security package
> and you dont have internet access for some reason.]
>
> Here are the questions that I have asked myself about clamav:
>
> Why did you not use the DAG model for packaging up clamav?

Changelogs indicate that the Fedora Extras package was written before
DAG's one ;)


> Why is clamav-data and clamav-update seperate from clamav when they
> get updated at the same time and are pretty much needed for every box
> using clamav?
>
> [We thought it was a fun and new way to package up things.]

Not really ;) Let us begin with -update: update functionality is
required/wanted both for the enduser tools (in the 'clamav' package) and
for the server instances (based upon 'clamav-server'). As 'clamav' and
'clamav-server' do not dependent each other, the update functionality
could be either packaged redundantly in both packages, or in a third
one. I preferred the latter way.

Additionally, 'clamav-update' introduces a dependency on cron which is
not required by the other packages.


'clamav-data' contains only the plain database and the same arguments as
above apply there. 'clamav-update' and '-data' are not in a common package as
they are somehow contradictory: '-update' overrides dynamically all static
files from '-data'.  Plus, shipping the virus-db in a separate package allows
update strategies where the database will be packaged separately and updated
with the usual 'yum upgrade' mechanism.


'-lib' is in an own package as there are projects requiring only the
libraries but not the tools (which introduce addition dependencies).
Reasons for '-devel' and '-milter' subpackages should be clear.


> How does one write a clamav-amavis, clamav-exim, clamav-mimedefang,
> clamav-postfix, etc RPM?

There is a 'clamd-gen' script in the -devel package. But it's not perfect
and has flaws. :(


> Why are these written as seperate script instances?
>
> [Answer seems to be "The best security design for running clamav is to
> seperate each use of clamav to a seperate user or UID. This helps from
> any possible compromises in clamav from affecting multiple services."]

Exactly. Using separate script instances requires less manual work than
providing a common -server package which must be modified manually.
E.g. usernames and socket pathnames can be preconfigured, and a 'clamd'
instance for a second independent services (e.g. mail vs. squid checker)
can be created easily.


> Why doesnt clamav run as root?
>
> [Answer seems to be "Running clamav as root is not a good idea. ..
> fill in the usual compromise as root problems.]

Yes. Another, minor issue is, that it might not work as expected.
E.g. on NFS based /home dirs, 'root' might be squashed to 'nfsnobody'
having nearly no rights in the user homes.

And, 'clamd' knows a 'SHUTDOWN' command and it is IMO a bad idea when
users can shutdown system services.




Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20050720/57dda779/attachment.sig>


More information about the fedora-extras-list mailing list