Description of problem: Software written using ghc requires SELinux allow_execmem=true priviledge. I ran into this when running darcs (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195820), but I am sure someone with Haskell knowledge can construct a much simpler test case exposing the problem. Version-Release number of selected component (if applicable): whatever ghc version was used to compile the darcs-1.0.7-1.fc5 package in Fedora Extras How reproducible: Every time. Steps to Reproduce: 1. Run "darcs get --partial http://fasodjf.xyz/ajdlfk/" Actual results: darcs: internal error: getMBlock: mmap: Permission denied Please report this as a compiler bug. See: http://www.haskell.org/ghc/reportabug Expected results: Invalid repository: http://fasodjkjf.xyz/ajdlfk darcs failed: Failed to download URL http://fasodjkjf.xyz/ajdlfk/_darcs/invento ry libcurl: couldn't resolve host Additional info:
The upstream ticket is at http://cvs.haskell.org/trac/ghc/ticket/738
The ghc darcs changelog has an entry from 2006-05-30 which is supposed to fix the problem. I haven't tested any recent snapshots of ghc-6.4.2 (which will become ghc-6.4.3) or ported that patch to back to ghc-6.4.2 yet, though.
http://darcs.haskell.org/ghc/_darcs/patches/20060530100211-760e2-44e4f7111796e3f91763f2442e83417db1187437.gz
I tried ghc-6.4.2.20060619-x86_64-unknown-linux and the problem still occurs with it.
Apparently the above patch only handles execheap not execmem. Dan, could some policy be added to selinux-policy to take care of this?
*** Bug 195820 has been marked as a duplicate of this bug. ***
chcon -t uncofined_execmem_exec_t EXECUTABLE should allow it execmem without having to set allow_execmem. But the app should really be fixed.
Upstream added support for execheap (above patch), but for execmem they object to having to go to such lengths to work around such a restrictive security policy. "GHC really does do runtime code generation, so it really does need some writable/executable memory." So they hope some policy can be added for ghc and programs using its RTS. Anyway setting "chcon -t unconfined_execmem_exec_t" in %post works for darcs at least, thanks.
Is this really just "working around such a restrictive security policy"? One could argue that making the writable/executable memory thing as secure as humanly possibly is just plain common sense, even if that requires writing code in one address and executing it in another. Alas, requiring execmem priviledges indicates that the code is not as secure as humanly possible. After looking at the code example (<URL:http://people.redhat.com/drepper/selinux-mem.html>) I think an implementation of that is possible, and the fact that this will improve all software written in Haskell makes it even more desirable.
*cough* After having had a look at ghc/rts/MBlock.c I don't think this can be trivially ported, at least not with my average C app programmer level knowledge. I won't have the time soon to climb the learning curve required (mmap alignment, C heap, ...), so if there are any other takers, feel welcome to have a go at it. :-)
Adding unconfined_execmem_exec_t context to programs that use ghc rts in ghc-6.4.2-3.fc6.
I cannot quite see the connection between the exec_mem problem and the read/write access to three log files mentioned in comment #12.
(In reply to comment #13) > I cannot quite see the connection between the exec_mem problem and the > read/write access to three log files mentioned in comment #12. I assume they were paste to the wrong bug... :)
Yes wrong bug. Removing by making it private.