> There is a known problem with Linux and Threads and Setuid, all together.
> If you setuid while running a threaded Tcl, then a number of
> system-related threads do not also change their uid.  Threads with
> different user IDs cannot signal each other (done under the covers
> by the Linux pthread library) and so things deadlock.

This is because of the `courageous' decision to implement threads as 
first-class processes under Linux, I presume.

Sounds like a fix is needed in pthreads, and I'm the man to hassle 'em until 
it gets done (or Linux collapses under the weight of its internal 
contradictions :)

First Q is what behavior would one reasonably expect?  This surely can't be 
happening only in tcl - any thread which changes its uid would break the 
pthreads lib?  Or is it some choice tcl implementation makes (in which case, 
it should suffice to change setuid.so to have the non-cooperative threads 
setuid at the same time as the child.)

> Its rather complex to fix this, although it has been done for AOLserver
> using a separate "binding" thread that listens on privileged ports.

Gack.  Privileged ports.  So it *has* to run as root.  Not a good choice, IMHO.

Colin.

> >>>[EMAIL PROTECTED] said:
>  > Hi,
>  > 
>  > I'm using  Linux 2.2.16, tclhttpd3.0.3 and tcl8.4.  Setuid (as compiled, fro
>      m 
>  > source) doesn't seem to work as I'd expect.
>  > 
>  > Here's what I've narrowed it down to:
>  > 
>  > sharedtech:/home/colin/Desktop/tclhttpdtest# tclsh8.4
>  > % package require setuid
>  > 1.0
>  > % setuid 33
>  > % whoami
>  > www-data
>  > % exit
>  > 
>  > At this point, it hangs (after exit, never terminating.)
>  > 
>  > The other symptom I noticed is that no fileevents seemed to trigger.  This 
>  > prevents my use of tclhttpd in setuid mode, so I'll either have to run as ro
>      ot 
>  > (and damn the consequences) or use a non-standard port.
>  > 
>  > I suspect, strongly, some adverse interaction between threads and the 
>  > setuid.so, although I'm not sure what.  Note that I've compiled these from 
>  > source.
>  > 
>  > Colin.
>  > 
>  > 
>  > 
>  > 
> 
> --    Brent Welch     <[EMAIL PROTECTED]>
>       http://www.ajubasolutions.com
>       Scriptics changes to Ajuba Solutions
>       scriptics.com => ajubasolutions.com
> 
> 
> 
> 


Reply via email to