On 2/17/06, Miles Lane <miles.lane@xxxxxxxxx> wrote: > Here are two Livna libraries that trigger the problem: > /usr/lib/xmms/Input/libmpg123.so: cannot enable executable stack as > shared object requires: Permission denied > /usr/lib/xmms/Visualization/libbscope.so: cannot enable executable > stack as shared object requires: Permission denied It's not just the "2nd"/3rd party repos; I've been alpha testing the Linux Second Life client, and I have to chcon -t textrel_shlib_t and some execstack -c as well on their libs to get the thing to run. The execstack thing I can see being something that needs to be changed in their build process so the libs are flagged right, but what's the right way to handle setting SELinux file contexts when installing external programs? Is there some way they can/should be building these such that they don't need relocation? Are they going to have to provide a special install script that sets proper contexts on the libs at runtime? Or should they be using star instead of tar? (Does textrel_shlib_t even make sense universally in all SELinux setups?) How do you convince distributors of 3rd-party programs to take SELinux into account when it's still a tiny fraction of the (already tiny) Linux userbase? Unfortunately it's problems like these that are probably inhibiting the use of SELinux outside the server space most. I know I've been turning SELinux completely off since FC2 rawhide era, and only in the last month or so have been brave enough to try it, and it has not been fun. --wes -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list