thread pool helpers

[tridge at samba.org]

-----BEGIN PGP SIGNED MESSAGE-----
Hi Jerry,

> Nope.  Access checks are in users space. 

do you do anything to combat the race conditions? For example, a user
might exploit a user space access check by doing this:

  while :; do
  	ln -sf /etc/shadow /home/baduser/myfile.txt
  	ln -sf /home/baduser/innocent.txt /home/baduser/myfile.txt
  done

then try to access myfile.txt via SMB. If the access check happens
while the file points at innocent.txt and the real open happens while
pointing at /etc/shadow then the user will end up opening
/etc/shadow. Implementing the above hack in C raises the chances of
success as well.

You can do inode number checks to combat this a bit, but that doesn't
work for newly created files in sensitive locations.

>  However, for platforms that could give me a per thread setreuid(),
> I would look at using that.

strangely enough, the Linux kernel can give you that, if you bypass
glibc and use syscall() to change your euid.

> I (or someone else here) will also probably look at abstracting the
> threading call we make.  Mainly all we need is shared memory,
> mutexes, and shared exclusive locks.  Stuff that any proper
> threading library would give you.  I don't think in the newer code
> that we exercised thread cancellation much, but that is an issue in
> the dcerpc runtime.

Rusty is currently trying to build "libantithread" which tries to
provide this functionality on top of fork().

See http://ccan.ozlabs.org/info/antithread.html

Cheers, Tridge