Bug 139741

Summary:	ClamAV creates a user; its home directory does not exist
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Alejandro Forero <bachue>
Component:	Other	Assignee:	Reinhard Max <max>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Alejandro Forero 2005-12-16 20:43:10 UTC

Installation of the ClamAV package creates a vscan user.  However, its home directory does not exist (I suspect another package might create it).

The clamav package should either:

1. Depend on the package that creates this directory (assuming it does require that package, which I think is unlikely),

2. Create this directory itself.  In this case I would suggest to name it something other than “amavis” (why “amavis”, call it “clamav” or something like that).

3. Perhaps use /var/lib/clamav as the home for this user.

I suppose #2 would be the best option.

Comment 1 Reinhard Max 2005-12-20 10:02:18 UTC

The vscan user was initially created by the amavis package. As the clamav package doesn't need the user it runs under to be able to log in, or to have an existing home directory, I don't see a reason to change anything.

Can you give me one?

BTW, the main reason why we have ClamAV on the distribution is for scanning emails in conjunction with the amavisd-new package, which does contain the home directory of the vscan user.

Comment 2 Alejandro Forero 2005-12-20 12:06:56 UTC

Having a package (clamav) create a user (vscan) and then having a separate package (amavis-something) create that user's home directory is, imo, bad design, specially when the original package is useful without the second and does not depend on it.
I think we all agree that ClamAV is useful in many configurations other than “scanning emails in conjunction with the amavisd-new package”.
In my case, clamav is useful without amavis; I use it for scanning virus in my emails, as I describe in https://cgi.afc.no-ip.info/svnwiki.cgi/default/sles-mail-server, using a 20-lines script as Postfix's content-filter.
This bad design doesn't only affect your users: in the future you (Suse developers) might want to have other packages use clamav and it'll affect you as well.

I think you have two options:

1. If you only intend for clamav to be used in conjunction with amavis, you should state this with a dependency.  Although this would be consistent with the “clamav is only included to be used with amavisd-new” stance, this would be a very bad option, since, as I said, clamav is useful on its own.

2. If, on the other hand, you acknowledge that clamav is useful without amavis then, by all means, change the name of ~vscan (:s/amavis/vscan/ on it) and have it created as a result of installing clamav.  This wouldn't break anything (since, obviously, you'd also change “amavis” to use that directory, if needed) but it would make your distribution more usable (I think admins can be expected to, well, expect that any users created as the result of installing packages have existing home directories).

Comment 3 Reinhard Max 2005-12-20 14:28:17 UTC

I see some slight ugliness, but absolutely nothing that is broken and needs fixing. ClamAV needs a UID to run the daemon under, but it doesn't need that user's home dir. So, as long as you can't provide me with some proof, that this directory is needed, I'll leave it as it is. Changing it would require some serious testing so that existing configurtations don't break when the packages are updated, for which I won't have time in the forseeable future.

Comment 4 Alejandro Forero 2005-12-21 16:33:32 UTC

I fail to see how having the ClamAV package create the home directory for the user it creates (ok, call it “amavis”, shrug) would break anything.  Do you think something might depend on this directory not existing?

Comment 5 Reinhard Max 2005-12-21 16:55:03 UTC

Creating the home directory under it's current name indeed wouldn't break anything, but changing the directory name, as you requested before, breaks existing configurations that depend on the current location of things.