Problems with pthreads in a chroot?

[Ed W]

  Hi Natanael

Thanks for responding

> Or you could just use Alpine Linux[2]. After all, x86 uclibc +
> grsecurity kernel (including pax) is our main focus ;)

Sure - actually my current project uses very similar to your alpine 
linux installation, only starting with a gentoo overlay.  I would very 
happily share any improvements I make however, normally you are ahead of 
me and I usually find the solutions to most uclibc questions are in your 
tree!

I think I would struggle to switch to using your build tool at present 
because I'm trying to build a modular setup rather like slax.  The idea 
is target a low ram target (which I think rules out running from 
ramdisk) and use aufs to build a modular installation where we have a 
base installation, but overlay more functionality for instances where 
it's needed. This would make for a very simple "package manager".  
Please tell me that this would be straightforward to build using Alpine 
and we should talk more off-list?  Last time I looked you pretty much 
mandated building an installation which only ran from ram?


However, your git tree suggests that you compile your uclibc without 
SSP?  Can you comment on whether SSP works for you?

> fwiw, for us the nptl from git have been better/more stable than any
> other threading implementation before. Infact, for x86, uclibc git
> master have been better than any previous release, ever. (at least up
> to the point config parser stuff got committed - but i think those
> issues are fixed to now)

OK, I'm going to try nptl now.  (I couldn't actually get new 
linuxthreads to compile)

Incidently I had a response from Brad at grsec:

> Can you check for calls to mmap with PROT_READ | PROT_WRITE | PROT_EXEC?
>
> uclibc is likely trying to create executable stacks.  Removing the
> PROT_EXEC in the protection flags in the source should solve the
> problem.  Otherwise you'll have to turn mprotect off on the binaries, as
> PaX no longer silently demotes RWX mappings to RW.
>
> -Brad

Can anyone smarter than me comment on that?  I do in fact see such a 
call in linuxthreads.old/manager.c

Thanks

Ed W