Re: Changes from 5.2.1 to 5.3 (theads / signal handling)

[Julian Elischer <julian@xxxxxxxxxxxx>]

Jose Marcio Martins da Cruz wrote:

> Julian Elischer wrote:
>
> > Jose Marcio Martins da Cruz wrote:
>
>
> > > So, if I understood, the better I can do is, instead of letting the 
> > > child follow
> > > a different path after the fork, he shall better do an exec of 
> > > another thing and
> > > start a clean process...
> > >
> > >  
> >
> > often what is done is to exec itself again with a different argument 
> > to make it know it is the child.
> >
> > why do you need to fork? why not just use more threads?
>
>
> This is a security issue. The application is a sendmail mail filter. 
> For many reasons the filter may die : an attack may succeed or there 
> may be a bug.
>
> The father is a supervisor only. He launches the child which is the 
> real filter. From time to time, the father checks if the filter is 
> alive and running (not blocked) - this is done by a non blocking wait 
> and a pipe between the father and the child. If there is a problem 
> with the child (died of blocked), the father does some clean up and 
> launches a fresh child.


sounds like the parent need not be threaded yet.

> I use a different process instead of more threads because a problem 
> with a thread can compromise all the process.
>
> This application runs fine under Solaris (four years long now).


Each implementation has different side-effects
On FreeBSD 6, try the libthr() threading library.

> Well, I definitely shall try to change this architecture, at least for 
> FreeBSD and maybe Linux too.
>
> > I can suggest the threads programming book
> > Programming with POSIX Threads
> > by
> > David R. Butenhof 
>
>
> Thanks, I have it. I read it long time ago...