From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.0 (like Gecko) Description of problem: I don't think that openoffice needs READ/WRITE/EXEC memory access. I believe that libsoffice.so should be changed to not require this. From strace: mmap2(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EACCES (Permission denied) gdb backtrace: #0 0x00456402 in __kernel_vsyscall () #1 0x0097a079 in raise () from /lib/libc.so.6 #2 0x0097b613 in abort () from /lib/libc.so.6 #3 0x00680820 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #4 0x0067e555 in std::set_unexpected () from /usr/lib/libstdc++.so.6 #5 0x0067e586 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0x0067e68a in __cxa_throw () from /usr/lib/libstdc++.so.6 #7 0x00d0410c in operator delete () from /usr/lib/openoffice.org2.0/program/libsoffice.so #8 0x00d0421c in operator new () from /usr/lib/openoffice.org2.0/program/libsoffice.so #9 0x03246713 in _STL::__node_alloc<true, 0>::_S_chunk_alloc () from /usr/lib/openoffice.org2.0/program/libstlport_gcc.so #10 0x0324680b in _STL::__node_alloc<true, 0>::_S_refill () from /usr/lib/openoffice.org2.0/program/libstlport_gcc.so #11 0x032468c3 in _STL::__node_alloc<true, 0>::_M_allocate () from /usr/lib/openoffice.org2.0/program/libstlport_gcc.so #12 0x0324ad04 in _STL::_String_base<char, _STL::allocator<char> >::_M_allocate_block () from /usr/lib/openoffice.org2.0/program/libstlport_gcc.so #13 0x0324a229 in _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char> >::basic_string () from /usr/lib/openoffice.org2.0/program/libstlport_gcc.so #14 0x0329123d in _STL::_Locale_impl::_Locale_impl () from /usr/lib/openoffice.org2.0/program/libstlport_gcc.so #15 0x0329191a in _STL::_Locale_impl::make_classic_locale () SE Linux audit log entry: type=AVC msg=audit(1137990425.478:94): avc: denied { execmem } for pid=12529 comm="scalc.bin" scontext=rjc:system_r:unconfined_t:s0-s0:c0.c255 tcontext=rjc:system_r:unconfined_t:s0-s0:c0.c255 tclass=process type=SYSCALL msg=audit(1137990425.478:94): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=10000 a2=7 a3=22 items=0 pid=12529 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="scalc.bin" exe="/usr/lib/openoffice.org2.0/program/scalc.bin" Version-Release number of selected component (if applicable): 2.0.1.1-7.2 How reproducible: Always Steps to Reproduce: 1. 2. 3. Additional info:
Executable writable mmaped memory is required for OOo's UNO remote bridges to work, as I found to my cost previously. http://qa.openoffice.org/issues/show_bug.cgi?id=52428
Is it required? The URL you cite above has no information on what the exec/read memory region is used for. It cites the below URL: http://qa.openoffice.org/issues/show_bug.cgi?id=47132 The bug #47132 on the OOo site has the following text: "In bridges::cpp_uno::shared::VtableFactory::createBlock/flushCode, use executable memory for the code snippets (and thus for the vtables also, although this would not be necessary), and then generally use non-executable memory for the heap. (See, for example flushCode for msvc_win32_intel.) Some new function like rtl_allocateMemory(size, alloc_flags) is necessary in sal." No explanation of why the code snippets might require executable memory. OOo is a large complex program that often uses data from untrusted sources. Write/execute memory access is not something that we want. If nothing else it would be good if there was an option for the pyuno bridge to be disabled if write/execute was not permitted.
The task listed there is the task for isolating the parts of the code which *require* executable heap from the rest of the code which doesn't require executable heap. The bits of code which need executable heap are the remote uno bridges, one of which is the pyuno python bridge thogh there are a few others, If the above task really should be completed before hacking out the global PROT_EXEC
*** This bug has been marked as a duplicate of 178971 ***