Re: Amavisd does not start

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux