Bug 178670 - libsoffice.so wants write/exec memory
libsoffice.so wants write/exec memory
Status: CLOSED DUPLICATE of bug 178971
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Depends On:
  Show dependency treegraph
Reported: 2006-01-22 23:31 EST by Russell Coker
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-26 03:28:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 47132 None None None Never
OpenOffice.org 52428 None None None Never

  None (edit)
Description Russell Coker 2006-01-22 23:31:26 EST
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:  
-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):

How reproducible:

Steps to Reproduce:

Additional info:
Comment 1 Caolan McNamara 2006-01-23 03:40:42 EST
Executable writable mmaped memory is required for OOo's UNO remote bridges to
work, as I found to my cost previously.
Comment 2 Russell Coker 2006-01-23 22:01:18 EST
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:  
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. 
Comment 3 Caolan McNamara 2006-01-24 03:58:45 EST
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
Comment 4 Caolan McNamara 2006-01-26 03:28:45 EST

*** This bug has been marked as a duplicate of 178971 ***

Note You need to log in before you can comment on or make changes to this bug.