though it looks like you might need to put in effort into getting per-thread uid's for freebsd/macosx when they make that available, and you're assuming they're running a recent glibc. Depending on complexity, it can't hurt to ensure you're not going to hit into per-thread uid/gid's. I'm of two minds about glibc doing this. This was a particular favourite bug class of mine :)
It seems that there is a linux distro which uses uclibc, which does not emulate the glibc behaviour:
Actually, from a quick google perhaps ensuring all threads run after chroot / dropping privileges might be a good idea.
- http:// wiki.freebsd. org/Per- Thread% 20Credentials www.cocoabuilde r.com/archive/ cocoa/33107- cthread- fork.html
- http://
though it looks like you might need to put in effort into getting per-thread uid's for freebsd/macosx when they make that available, and you're assuming they're running a recent glibc. Depending on complexity, it can't hurt to ensure you're not going to hit into per-thread uid/gid's. I'm of two minds about glibc doing this. This was a particular favourite bug class of mine :)
It seems that there is a linux distro which uses uclibc, which does not emulate the glibc behaviour:
http:// dl-4.alpinelinu x.org/alpine/ v2.2/main/ x86/ <-- has qemu packages.
we can use http:// paste.pocoo. org/raw/ 438497/ to emulate qemu's behaviour
# ./test
[main] my [ug]id is 100/100
[thread] my [ug]id is 0/0
^-- the qemu thread would be running as root
running the same code under glibc (without grsecurity chroot_findtask), and it will drop privileges as you'd expect on recent glibc.