Bug#188475: /usr/bin/localedef confilicts with PAX

[GOTO Masanori <gotom@debian.or.jp>]

At Mon, 14 Apr 2003 12:48:00 +0200,
mikee wrote:
> >   The malloc_initialize_hook is glibc's malloc() hook routine.  I guess
> >   this program gets also sigsegv:
> >   
> [snip]
> >   
> 
> no sigsegv:
> 
> mim:~# gcc -o testpax testpax.c
> mim:~# ./testpax
> malloc
> 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
> mim:~#
> 
> >  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 pageexec@freemail.hu (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.

Regards,
-- gotom