Dear All, On Mon, Jun 08, 2026 at 04:54:21AM +0200, Damjan Jovanovic wrote:
> On Sun, Jun 7, 2026 at 10:43 PM Arrigo Marchiori <[email protected]> wrote: > > > Hello Damjan, All, > > > > On Sun, Jun 07, 2026 at 10:00:37PM +0200, Damjan Jovanovic wrote: > > > > > Could this be the problem? I think it must be, OpenGrok shows there's > > > nowhere else in OpenOffice we use PROT_EXEC. > > > > > > At least on lines 105 and 111 it's granting read, write and execute > > > permissions together: > > > > > > File main/bridges/source/cpp_uno/shared/vtablefactory.cxx: > > > > > > 77 extern "C" void * SAL_CALL allocExec(rtl_arena_type *, sal_Size * > > > size) { > > > ... > > > 96 sal_Size n = (*size + (pagesize - 1)) & ~(pagesize - 1); > > > 97 void * p; > > > 98 #if defined SAL_UNX > > > 99 p = mmap( > > > 100 0, n, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, > > > 101 0); > > > 102 if (p == MAP_FAILED) { > > > 103 p = 0; > > > 104 } > > > 105 else if (mprotect (static_cast<char*>(p), n, PROT_READ | > > > PROT_WRITE | PROT_EXEC) == -1) > > > 106 { > > > 107 munmap (static_cast<char*>(p), n); > > > 108 p = 0; > > > 109 } > > > 110 #elif defined SAL_W32 > > > 111 p = VirtualAlloc(0, n, MEM_COMMIT, PAGE_EXECUTE_READWRITE); > > > 112 #elif defined(SAL_OS2) > > > 113 p = 0; > > > 114 DosAllocMem( &p, n, PAG_COMMIT | PAG_READ | PAG_WRITE | > > > OBJ_ANY); > > > 115 #endif > > > 116 if (p != 0) { > > > 117 *size = n; > > > 118 } > > > 119 return p; > > > 120 } > > > > > > There are already some workarounds for SELinux in this directory, but we > > > probably need more. > > > > I don't know SELinux well, nor those syscalls. So I cannot confirm, > > unfortunately. > > > > Do you think we should put a ``workaround for SELinux'' in place, > > rather than running execstack as I was suggesting in PR #483? If so, > > could you please point me to some documentation? I have access both to > > an ``old'' build VM and a ``new'' Linux-based system, so I can easily > > do tests. > > > > > Let's understand this better first. > > This is an excellent blog post on the topic: > https://linuxvox.com/blog/stacks-are-executable-even-with-noexecstack/ > > Now as per that article, note how both FreeBSD and Linux already link with > -Wl,-z,noexecstack for libraries, at least with gbuild: > > main/solenv]$ grep execstack * -R > gbuild/platform/freebsd.mk:gb_Library_TARGETTYPEFLAGS := -shared > -Wl,-z,noexecstack > gbuild/platform/linux.mk:gb_Library_TARGETTYPEFLAGS := -shared > -Wl,-z,noexecstack > > but even this seems unnecessary, as that should be the default with GCC >= > 4.1. > > A quick audit on my build tree > (main/instsetoo_native/unxfbsdx/Apache_OpenOffice/installed/install/en-US/openoffice4/program) > shows how nothing has executable stacks: > > find . -type f | while read i; do readelf -l "$i" 2>/dev/null| grep > GNU_STACK|grep E; done > (no output. You can remove the "grep E" to see every GNU_STACK entry has > only "RW" permissions.) I had to add option --wide to readelf(1). Here is an interesting thing: - the solver directory from my build of AOO41X with openSUSE 16.0, GCC 13.4.0, has no files with executable stack. - the solver directory from my build of AOO41X with CentOS 5, GCC 4.1.2, has the following file with executable stack: ./4116/unxlngx6.pro/lib/libraptor2.so.0 So I was probably addressing the wrong problem: libraptor2.so.0 shall not require executable stack, instead. I am having a hard time understanding why this is happening, though. Best regards, -- Arrigo --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
