httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: [Fwd: Apache httpd vulenrabilities]
Date Wed, 30 May 2007 22:09:14 GMT
Ruediger Pluem wrote:
> 
> 
> 
> On 05/30/2007 09:45 PM, Jim Jagielski wrote:
> > 
> > On May 30, 2007, at 2:57 PM, Ruediger Pluem wrote:
> > 
> >>
> >>
> >> On 05/30/2007 08:10 PM, Jim Jagielski wrote:
> >>
> >>>
> >>> On May 29, 2007, at 5:28 PM, William A. Rowe, Jr. wrote:
> >>>
> >>>>
> >>>> Essentially, PID tables need to move from the score to a local  process
> >>>> list only in the parent, and unshared.  That would solve the  80/20
of
> >>>> this entire class of issues.
> >>>>
> >>>
> >>> Yes... Of course, it doesn't even need to be that extensive.
> >>> If the parent process simply keeps in local storage a
> >>> list of PIDs and before it does anything to the child
> >>> process (send signal), it checks that the PID in the
> >>> scoreboard is also in its own list, and only
> >>> continues if it is.... This means that the scoreboard
> >>> stays as is and the parent process just needs a
> >>> small list of pid's added to it, plus some minor
> >>> logic.
> >>
> >>
> >> This is also my thought on this. Maybe the logic could be extended
> >> somewhat so that the parent cross checks / sanity checks the number of
> >> pids in its local storage and the number of active pids (a.k.a "non 
> >> empty"
> >> slots) in whatever state they are every time it decides that it needs
> >> to start additional childs / kill childs. This should avoid / reduce
> >> issues #1 / #4.
> >>
> > 
> > :) My thoughts exactly...
> > 
> > The only issue with pulling parent out of scoreboard is,
> > of course, the backwards compatibility with modules that
> > may be interested in it...
> 
> Sorry for being confused now. I thought the idea was to have an additional
> local pid list in the parent for cross / sanity checking. The scoreboard
> remains as it is (including the pids). So what could modules possible miss
> after the patch?
> 

Not sure where the confusion is... the idea is to keep the scoreboard
exactly as-is (as noted above, pulling out the parent parts (pid),
would be a major issue for backwards compatibility), and just add
pid-checking logic (and a local store of pids) in the parent process.
Thus, it's completely transparent and no changes to the scoreboard
or any entities that use it (except for the mentioned parent-side
checking, 'natch) :)

"The only issue..." refers to the problems if we try to restructure
the scoreboard instead, which is good for 2.4/3.0 but not for 2.2, 2.0
and 1.3... Any patches that tried to address the issue using that
method would be problematic. Hence my thoughts to just have local
storage for checking and keeping scoreboard as-is.
-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
	    "If you can dodge a wrench, you can dodge a ball."

Mime
View raw message