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.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
