Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an application I test at work, that has always failed installation on systems with SELinux enabled. Our published workaround involves issuing a chcon command for the library-file at the center of the failure.

chcon -t textrel_shlib_t /usr/lib/ourfile.so.1.0.20

In RHEL5, this has worked for us, and allows the application to function correctly, without having to completely disable SELinux.

Under RHEL6, the chcon command gives no errors, but we still see the same error, when our application is started as a daemon, via /etc/init.d/ourapp

My primary concern is figuring out an updated workaround (the application library in question is submitted to an external certification process, and can't be changed for another 6 months), but I'm also curious if this indicates an intentional change from RHEL5 to RHEL6.

share|improve this question
add comment

1 Answer 1

The Unofficial SELinux FAQ contributes this workaround.

This is caused by an extension to Linux called Exec-Shield. It prevents programs from executing code on the stack, mitigating stack smashing attacks.

Most shared libraries do not need an executable stack, therefore you should mark the library as not needing an executable stack via:

execstack -c /usr/lib/ourfile.so.1.0.20

After using execstack, test the program to ensure that it still runs. If you have some bad code in there that actually tries to execute code on the stack, it will crash.

share|improve this answer
    
As I mentioned, the library isn't fixable for several months, and it does require execution of the stack, so this 'fix' doesn't help my current situation, nor explains why chcon worked under RHEL5, but doesn't under RHEL6. –  Don Simon Sep 25 '12 at 14:53
    
You're stuck with fixing the library and waiting six months, then. I have no idea why your chcon was all you needed to make it work on EL5; it should not have worked as Exec-Shield is enabled by default on EL5 as well. –  Michael Hampton Sep 25 '12 at 14:59
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.