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.)
It's of course possible that the stack is made executable at run-time,
because when libraries needing execstack are loaded, they poison the stack
of the entire application. Even this can be checked:
procstat vm PID |grep rwx
(or on Linux, use "cat /proc/PID/map")
PID START END PRT RES PRES REF SHD FLAG TP
PATH
6460 0x89b9a5000 0x89bc15000 rwx 134 134 1 0 ----- sw
6460 0x89bf35000 0x89c1a5000 rwx 186 186 1 0 ----- sw
6460 0x8a346d000 0x8a36dd000 rwx 43 43 1 0 ----- sw
The "sw" node type means swap.
Each of those 3 memory mappings is 2.4375 MiB in size, and probably made by
the bridges code from my earlier post, but isn't a stack.
A stack would have flag "D" (grows Down), but none of the mappings with
flag "D" have permission "x".
So it looks like on FreeBSD noexecstack already works like it should, at
build time and run time.
Now why is it broken on Linux? I don't have time to check right now, please
try the above on Linux and post what you get?
> Best regards,
> --
> Arrigo
>
>
>
Regards
Damjan
