https://bugs.freedesktop.org/show_bug.cgi?id=72755
--- Comment #9 from Stephan Bergmann <[email protected]> --- (In reply to comment #5) > I'm trying to figure out how important this is as well, to help in > apparmoring LO. Right now the .exec fails and the libreoffice still comes > up, but I don't see it falling back to /tmp. Can this just be removed? What exactly do you mean with "the .exec fails"? Looking at the #ifdef USE_DOUBLE_MMAP definition of VtableFactory::createBlock in bridges/source/cpp_uno/shared/vtablefactory.cxx, there are four different things that can go wrong: 1 mkstemp fails 2 posix_fallocate resp. ftruncate fails 3 mmap(..., PROT_READ|PROT_WRITE, ...) fails 4 mmap(..., PROT_READ|PROT_EXEC, ...) fails If (1) or (2) fails when trying $HOME, it will apparently not try again with /tmp, but just use a plain (read, write, non-exec) allocation. Such a non-exec fallback allocation would make creation of the synthesized vtable work, but only when LO would later try to make a call via that vtable, executing the code generated into that non-exec fallback allocation would fail (with a SIGSEGV or SIGBUS or similar). However, whether LO would later make such a call depends on how you use LO. If you just start it up and shut it down again, chances are that you never trigger such a failing call. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
