Bug#188475: /usr/bin/localedef confilicts with PAX
At Mon, 14 Apr 2003 12:48:00 +0200,
> > The malloc_initialize_hook is glibc's malloc() hook routine. I guess
> > this program gets also sigsegv:
> no sigsegv:
> mim:~# gcc -o testpax testpax.c
> mim:~# ./testpax
> mim:~# chpax -v testpax
Hmm, sorry my misunderstanding test program.
> ----[ chpax 0.2 : Current flags for testpax ]----
> * Paging based PAGE_EXEC : enabled (overridden)
> * Trampolines : not emulated
> * mprotect() : restricted
> * mmap() base : randomized
> * ET_EXEC base : not randomized
> * Segmentation based PAGE_EXEC : enabled
> mim:~# grep PAX /var/log/syslog
> > Do you have any problems in X11 or java with pax?
> i don't use x11 or java - that box is my lan gateway ;-)
> i also received mail from firstname.lastname@example.org (pax team):
> > just saw your bugreport on debian. what happens here is that localedef
> > uses gcc nested functions which are invoked by placing some small code
> > on the stack which happens to be non-executable, hence the task will
> > be killed. chpax -sp disables both kinds of non-exec features on the
> > target (even if technically -s is enough since you didn't compile the
> > other feature in the kernel). a better solution would be to rewrite
> > localedef to not use nested functions.
> i suppose it explains the problem but solution depends on politics:
> - patch glibc to be PAX/enhanced security/ friendly OR
> - reconfigure PAX to be glibc friendly
> i like first solution but i won't rewrite localedef tool myself
> so this is my wish ;-)
This means that all programs using gcc nested functions (so trampoline
technique) are totally unusable on pax environment?
And do you think "chpax.sh" is useful for this purpose? If so, I
think the temporary solution is that chpax packages supports chpax.sh.