>>>Colin McCormack said:
> Sounds like a fix is needed in pthreads, and I'm the man to hassle 'em
Cool!
> 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.)
Well, it certainly affected AOLserver, a C server application that embeds Tcl.
But, all the socket handling is done outside of Tcl in AOLserver, so the
problems are generic.
> > 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, IM
HO.
The dance goes something like this.
AOLserver starts with a command line argument specifying a uid.
It forks a process to wait on its various listening sockets.
The main process does a setuid.
Connections are accepted on the listening socket
and dispatched to connection threads.
You have to do this before initializing Tcl, because it
starts a thread during initialization
(when compiled with TCL_THREADS enabled).
I'm not fully clear on how the binding and accepting is done.
I do know that AOLserver forks a process very early, before
doing the setuid(), and this "binder" process opens the
listening socket. Then, either it also accepts connections
and then passes those sockets to the original server, or
it passes the listening socket back to the original server.
The socket passing is done via an ability to pass file descriptors
over sockets on Unix.
Anyway, its all rather complex. What TclHttpd would simply like to do is:
1) run tclsh that doesn't know about setuid.
2) open the listening socket
3) do the setuid
-- Brent Welch <[EMAIL PROTECTED]>
http://www.ajubasolutions.com
Scriptics changes to Ajuba Solutions
scriptics.com => ajubasolutions.com
