Re: Amavisd does not start

[Paul Howarth <paul@xxxxxxxxxxxx>]

Justin Willmert wrote:
> Chris Jones wrote:
> > Justin Willmert wrote:
> > > I guess next I'd suggest looking at the init.d file and seeing what 
> > > it is doing. I do it sometimes when something isn't working right and 
> > > try to recreate the steps by hand, seeing where it goes wrong. 
> > > Sometimes it leads me to the problem area where I can finally get an 
> > > idea of what should be changed.
> > Following your suggestion, I put the following commands through in a 
> > terminal session:-
> >
> > [commands clipped]
> >
> > I am even more puzzled. The normal 'service amavisd start', 'service 
> > amavisd stop', and 'service amavisd restart' all fail for one reason 
> > or another, yet this technique seems to do the job.
> As I see you figured out from another post, the culprit was SELinux...I 
> find many times that *is* the problem, so doing a setenforce 0 and then 
> trying to start the program usually helps a lot. Just to give you some 
> info into why the commands worked from the command line and not from the 
> normal service amavisd start method was because of how SELinux handled 
> the commands...
>
> When you run the command service amavisd start, somewhere along the way 
> amavisd is started by a program that is running under init_t context (I 
> think), and the policy for amavisd says that an amavis_exec_t should 
> change to amavis_t (<-Not sure of the context there either) when in an 
> init_t context.
>
> Your command line on the other hand is running as unconfined_t. There 
> aren't any policy commands saying that amavis_exec_t should change to 
> amavis_t running context under unconfined_t, so amavisd is left as an 
> unconfined_t process, in which amavisd isn't blocked from reading the 
> files it wants to.
>
> I'm not 100% sure of that, but I think that is at least a mostly 
> truthful about how SELinux works. I've been trying to learn SELinux 
> lately, and knowing some of this helps when debugging why a program 
> isn't working as it should. Anybody more knowledgeable should feel free 
> to correct me...I'd like to understand better myself.

That's a fair summary of what's happening. So when you start amavis 
manually, it ends up running in the "unconfined" domain rather than the 
"amavis" domain, and isn't as restricted in what it can do.

The same thing happens if you set the amavis_disable_trans SELinux 
boolean, which disables the transition from initrc_t to amavis_t.

Setting this boolean is what happens if you set amavis as a "trusted 
application" in system-config-securitylevel; you're saying that you 
trust the application to run unconfined by SELinux.

Paul.