On Thu, Jul 14, 2011 at 11:37 AM, Andrew Griffiths
<email address hidden> wrote:
> Regarding the threads having different privilege level, I have isolated
> that to being related to my grsecurity configuration (more specifically,
> chroot_findtask will block it).
>
> While it's still an issue on older glibc where the setuid/setgid code
> does not enforce it across all threads, it may not be high priority
> since fixing it would be a lot more effort.
Wow, just learnt something new that glibc does behind our backs :). I
see it uses SIGRTMIN+1 to signal threads and get them to do the set*id
system calls.
I'm glad it does this because although most QEMU threads should be
started after command-line parsing, I can think of instances where we
might start a thread before -runas is completed.
On Thu, Jul 14, 2011 at 11:37 AM, Andrew Griffiths
<email address hidden> wrote:
> Regarding the threads having different privilege level, I have isolated
> that to being related to my grsecurity configuration (more specifically,
> chroot_findtask will block it).
>
> While it's still an issue on older glibc where the setuid/setgid code
> does not enforce it across all threads, it may not be high priority
> since fixing it would be a lot more effort.
Wow, just learnt something new that glibc does behind our backs :). I
see it uses SIGRTMIN+1 to signal threads and get them to do the set*id
system calls.
I'm glad it does this because although most QEMU threads should be
started after command-line parsing, I can think of instances where we
might start a thread before -runas is completed.
Stefan