On Jun 1, 2007, at 3:35 PM, Jim Jagielski wrote:
FWIW, I've created a branch of the work in progress, so
people can follow along and provide comments and patches :)
http://svn.apache.org/repos/asf/httpd/httpd/branches/httpd-pid-
table
this is based off of trunk, so once we have this
On Jun 1, 2007, at 2:13 PM, Jim Jagielski wrote:
On Jun 1, 2007, at 11:39 AM, Jim Jagielski wrote:
I will likely just commit the updated patch, and we
can fine-tune via commits rather than having rounds
of patches posted :)
I just started on the trunk patches, not sure when they
will be
On Jun 1, 2007, at 11:39 AM, Jim Jagielski wrote:
I will likely just commit the updated patch, and we
can fine-tune via commits rather than having rounds
of patches posted :)
I just started on the trunk patches, not sure when they
will be done... anyway, I was think that in addition to
the
On Jun 1, 2007, at 10:45 AM, Colm MacCarthaigh wrote:
On Fri, Jun 01, 2007 at 10:50:09AM -0400, Jim Jagielski wrote:
Should we get rid of it from the table here? Can we get away without
removing stale pids in general? What if they are recycled by the OS
for something else?
No, that's a good
On Fri, Jun 01, 2007 at 10:50:09AM -0400, Jim Jagielski wrote:
> >Should we get rid of it from the table here? Can we get away without
> >removing stale pids in general? What if they are recycled by the OS
> >for something else?
> >
>
> No, that's a good point. We should likely remove the
> pid fr
On Jun 1, 2007, at 10:19 AM, Colm MacCarthaigh wrote:
On Fri, Jun 01, 2007 at 10:05:26AM -0400, Jim Jagielski wrote:
- if (ap_scoreboard_image->servers[n].status != SERVER_DEAD &&
- kill((pid = ap_scoreboard_image->parent[n].pid), 0) == -1) {
- ap_update_child_sta
On Fri, Jun 01, 2007 at 10:05:26AM -0400, Jim Jagielski wrote:
> - if (ap_scoreboard_image->servers[n].status != SERVER_DEAD &&
> - kill((pid = ap_scoreboard_image->parent[n].pid), 0) == -1) {
> - ap_update_child_status(n, SERVER_DEAD, NULL);
> - /* just mark it as h
For 1.3, I'm looking at something like this...
Similar approach for 2.x...
Comments and feedback appreciated before I work on
"porting" to the 2.x trees:
Index: main/http_main.c
===
--- main/http_main.c(revision 543486)
+++ main
On 5/30/07 6:09 PM, "Jim Jagielski" <[EMAIL PROTECTED]> wrote:
> "The only issue..." refers to the problems if we try to restructure
> the scoreboard instead, which is good for 2.4/3.0
Scoreboard needs an overhaul anyway. So I wouldn't muck with it now. The
local pid table sounds fine.
--
Bri
On 05/31/2007 12:09 AM, Jim Jagielski wrote:
>
> "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
On May 30, 2007, at 3:09 PM, Jim Jagielski wrote:
Hence my thoughts to just have local
storage for checking and keeping scoreboard as-is.
+1 on this approach.
S.
--
Sander Temme
[EMAIL PROTECTED]
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
smime.p7s
Description: S/MIME c
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:
> >>>
>
> Es
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
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
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.
>>
>
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
Ruediger Pluem wrote:
>
> 2 weeks? The text in the reporters mail (see end of mail) speaks about
> May 16th, 2006. This would be about a year (and this is mentioned as
> reason for publishing) When did they actually send this to security@
> and to which ([EMAIL PROTECTED], [EMAIL PROTECTED])?
My
On 05/29/2007 11:28 PM, William A. Rowe, Jr. wrote:
> Ian Holsman wrote:
>
>>Hey Bill
>>
>>just to clarify these are LOCAL DoS attacks? ie you need access to the
>>machine (or the ability to execute php) in order for this to be an issue?
>
>
> AIUI all of these are loading modules of untrusted
Ian Holsman wrote:
> Hey Bill
>
> just to clarify these are LOCAL DoS attacks? ie you need access to the
> machine (or the ability to execute php) in order for this to be an issue?
AIUI all of these are loading modules of untrusted code (or a scripting
language which gives you the same effect.)
* Ian Holsman wrote:
> Hey Bill
>
> just to clarify these are LOCAL DoS attacks? ie you need access to the
> machine (or the ability to execute php) in order for this to be an issue?
Well, if your PHP script (running on mod_php) allows code injection, it's
also remotely exploitable. Untrusted co
Hey Bill
just to clarify these are LOCAL DoS attacks? ie you need access to the
machine (or the ability to execute php) in order for this to be an issue?
William A. Rowe, Jr. wrote:
Published - ergo moving discussion from security@ to [EMAIL PROTECTED]
Of course if in the course of this disc
Published - ergo moving discussion from security@ to [EMAIL PROTECTED]
Of course if in the course of this discussion, you uncover a new
edge case, feel free to move that thread back to [EMAIL PROTECTED]
to discuss your new discovery.
--- Begin Message ---
PSNC Security Team has got the pleasure to
22 matches
Mail list logo
