On Fri, 2006-02-17 at 10:10 -0700, Wes Shull wrote: > > > The execstack thing I can see being something that needs to be changed > in their build process so the libs are flagged right no it means their code need fixing to just work right automatically. It's Not That Hard(tm). There are basically 2 sources of such markings that are common 1) nested C functions 2) assembly files 1) needs a change in the code to make the code non-nested; nested functions are a gcc-only extension as well so are not a good idea in general 2) needs two simple lines added to the assembly file: .section .note.GNU-stack, "", @progbits .previous > , but what's the > right way to handle setting SELinux file contexts when installing > external programs? textrels are a serious build breakage. on x86 glibc sort of works around it, but it's still very bad. SELinux now disallows the workaround basically. It's almost always either a missing -fPIC on the compile line, not making the library position independent (which they HAVE to be), or using another .a library which isn't -fPIC compiled, with the same effect. on x86, glibc is nice enough to mess with the code to make it relocatable anyway sort of, but it's evil, ugly, fragile and just bad. > textrel_shlib_t even make sense universally in all SELinux setups?) no it means the library is misbuilt badly and needs fixing ;( labeling is just a "I mark this as known broken, please disable security checks for this" workaround, not a fix. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list