How and why does "setenforce 0" allow Java 7 to run? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

I've made some changes on a program I'm working on and I've updated Java from Java 6 to Java 7.

I am running the program on a CentOS 5.8 32-bit VM.

Before the Java update it worked fine.

Now the process isn't starting with the error:

 [root@CentOS-58-i-0 bin]# ./agent.sh start

 Starting Agent.....d. running (23442).
 Error: dl failure on line 864
 Error: failed /agent/jre/lib/i386/client/libjvm.so, 
 because /agent/jre/lib/i386/client/libjvm.so: 
 cannot restore segment prot after reloc: Permission denied

I've checked online and the solution/workaround for this is to run the command:

   setenforce 0

and it would work.

Reading the documentation on the setenforce command, I didn't understand what it does and how did it solve the problem.

So my questions are:

1. What may cause the error that prevents me from starting my process?
2. Why does the setenforce command solve it?
3. Please give a short explanation of what setenforce does in general.

Answer 1

1) what may cause the error that prevents me from starting my process ?

This problem is caused by SELinux enforcing an access policy which forbids that application changing the memory protection attributes of a memory segment

CentOS, Fedora, Scientific Linux and RedHat Entrprise Linux have SELinux set to "Enforcing" mode by default.

2) why does setenforce command solves it ?

3) short explanation of what setenforce does in general

Running setenforce 0 is switching SELinux to "Permissive" mode.

This "fixes" the problem, but it is not a good idea if your system is exposed. The idea of SELinux targeted access policies is to protect your system by limiting the things that your exposed services can do ... if they get hacked, for example. You have just turned that protection off.

A better approach is to:

• check the security / audit logs,
• figure out exactly what triggered the AVC alert
• decide if it is actually safe for the service to do what it is doing
• figure out a temporary fix using chcon to change the relevant security context or flags.
• implement a permanent fix by adding a local policy override.

But you need some SELinux skills / knowledge to pull that off.

In this particular case, an alternative (and significantly less dangerous) "quick fix" would be to run this:

# chcon -t textrel_shlib_t /agent/jre/lib/i386/client/libjvm.so

But note that a temporary security context change made using chcon is likely to be undone if you need to do a restorecon.