[Bug 60487] Core dumps in mpm_event during graceful restart

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60487

--- Comment #8 from Eric Covener  ---
(In reply to Yann Ylavic from comment #7)
> (In reply to Eric Covener from comment #2)
> > 
> > Maybe a good sanity check would be to look
> > for mpm_state == AP_MPMQ_STARTING when retained == NULL and no-op'ing it
> > altogether.  An even safer option might be to only handle the graceful
> > flavors w/ the new block, to avoid the chance a hard stop or hard restart is
> > ignored if we're missing something?
> 
> I think we should avoid touching anything scoped/static to the mpm module
> (dso) in a signal handler, otherwise any signal delivered while the module
> is unloaded might raise the fault.
> 
> That is: mpm_state, shutdown_pending, restart_pending and retained.
> 
> How about allocating them (in a struct) from ap_pglobal?

I assumed we wouldn't be able to enter the static functions that touch the
static variables, but I guess better safe than sorry.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60487] Core dumps in mpm_event during graceful restart

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60487

--- Comment #9 from Eric Covener  ---
(In reply to Eric Covener from comment #8)
> (In reply to Yann Ylavic from comment #7)
> > (In reply to Eric Covener from comment #2)
> > > 
> > > Maybe a good sanity check would be to look
> > > for mpm_state == AP_MPMQ_STARTING when retained == NULL and no-op'ing it
> > > altogether.  An even safer option might be to only handle the graceful
> > > flavors w/ the new block, to avoid the chance a hard stop or hard restart 
> > > is
> > > ignored if we're missing something?
> > 
> > I think we should avoid touching anything scoped/static to the mpm module
> > (dso) in a signal handler, otherwise any signal delivered while the module
> > is unloaded might raise the fault.
> > 
> > That is: mpm_state, shutdown_pending, restart_pending and retained.
> > 
> > How about allocating them (in a struct) from ap_pglobal?
> 
> I assumed we wouldn't be able to enter the static functions that touch the
> static variables, but I guess better safe than sorry.

although safer still might be ignoring those signals until an MPM can come back
up?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60487] Core dumps in mpm_event during graceful restart

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60487

--- Comment #10 from Yann Ylavic  ---
(In reply to Eric Covener from comment #9)
> > I assumed we wouldn't be able to enter the static functions that touch the
> > static variables, but I guess better safe than sorry.

Right, though the signals handlers (which look very similar if not exactly the
same for all *nix MPMs) and the associated globals could possibly live in a
static (non DSO) place too.

> 
> although safer still might be ignoring those signals until an MPM can come
> back up?

We might miss a shutdown/restart while restarting (this is case case already
currently since the _pending variables are reset in pre_config), but I think we
could avoid that too.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60739] SSLProtocol settings seem to have no effect

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60739

--- Comment #2 from David Favor  ---
The following also works oddly.

SSLProtocol -all +TLSv1

This enables TLS 1.0 + 1.1 + 1.2 rather than just 1.0 as expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60739] SSLProtocol settings seem to have no effect

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60739

--- Comment #1 from David Favor  ---
Setting SSLProtocols to -all produces expected behavior, which is an error
about no protocols.

This suggests the problem relates to setting TLSv1.2, which incorrectly seems
to also enable TLSv1.1 + TLSv1.0 so maybe this is the real problem.

The following also fail disabling TLSv1.

# SSLProtocol all -SSLv2 -SSLv3 +TLSv1.2 -TLSv1
# SSLProtocol -all +TLSv1.2 -TLSv1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60739] New: SSLProtocol settings seem to have no effect

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60739

Bug ID: 60739
   Summary: SSLProtocol settings seem to have no effect
   Product: Apache httpd-2
   Version: 2.4.25
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: mod_ssl
  Assignee: bugs@httpd.apache.org
  Reporter: da...@davidfavor.com
  Target Milestone: ---

Changes in SSLProtocol seem to be ignored.

This can be observed in all SSL testers I've used.

The testssl script provides an easy way to check this, without having to wait
for minutes (like SSLLabs) for output.

Problem can be shown via...

testssl --protocols https://davidfavor.com/

Environment - Apache-4.2.5 + OpenSSL 1.0.2k + Ubuntu Yakkety.

My goal == disable TLS 1.0 for some of my hosting clients who have PCI
requirements for this level of TLS to be disabled.

None of these permutations work. In fact, I can't find any SSLProtocol setting
which changes protocols at all. In all cases SSL2 + SSL3 are disabled + all TLS
versions are enabled.

Settings tried, that fail to disable TLSv1...

# SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
# SSLProtocol -All TLSv1.2
# SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

# SSLProtocol all -SSLv2 -SSLv3 -TLSv1
# SSLProtocol -all +TLSv1.2
# SSLProtocol TLSv1.2 -TLSv1
# SSLProtocol TLSv1.2
# SLProtocol -All +TLSv1.1 +TLSv1.2

SSLProtocol all -SSLv2 -SSLv3 -TLSv1

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60375] Apache httpd returns "200 OK" for a request exceeding LimitRequestBody when enabling mod_ext_filter

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60375

Joe Orton  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Joe Orton  ---
Many thanks Eric for fixing this!  trunk -> r1775770 trunk -> r1775832

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60375] Apache httpd returns "200 OK" for a request exceeding LimitRequestBody when enabling mod_ext_filter

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60375

--- Comment #3 from Joe Orton  ---
Oops. 2.4.x -> r1775832

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60088] mod_ext_filter did not work if post body size larger than 8192 bytes

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60088

Joe Orton  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Joe Orton  ---
Can you retest with 2.4.25?  I can't reproduce the error here from that
config/filter combination.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60487] Core dumps in mpm_event during graceful restart

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60487

--- Comment #3 from Jeff Wheelhouse  ---
"Did you take some explicit efforts to get a SIGHUP/WINCH sent during the load
of the module?"

No, unfortunately, it rears its ugly head all on its own.

"I am wondering if there is something else more likely to delay the startup in
practice, perhaps in Jacob's env?"

There's no overlap between Jacob P and I, so I can't speak for him, but our
environments definitely don't overlap.  (I.e. there is no cPanel in my
environment.)

"I do think it's more likely you have back-to-back graceful signals and just
ignoring the second is better.  Maybe a good sanity check would be to look for
mpm_state == AP_MPMQ_STARTING when retained == NULL and no-op'ing it
altogether.  An even safer option might be to only handle the graceful flavors
w/ the new block, to avoid the chance a hard stop or hard restart is ignored if
we're missing something?"

These are good points.

If I understand this correctly, basically ap_start_restart() is getting called
at the wrong time.  It expects to be called after "retained" is initialized,
but it's getting called before that.  That happens because the second restart
happens before the first restart has finished initializing it.

In other words, ap_start_restart() is getting called when the server hasn't
started.  So the patch I provided might really be addressing the effect, not
the cause.

It seems like a "correct" fix would cause ap_start_restart() not to be called
when the server hasn't been started, either by deferring the 2nd restart until
the first one is done or by ignoring it completely.

So, the types of safer/sanity checks you're talking about... would they
possibly be best-positioned higher up in the code?  If so, would that be in the
core, or is there something specific to mpm_event that isn't re-restarting
properly?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60487] Core dumps in mpm_event during graceful restart

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60487

--- Comment #4 from Jacob P  ---
Howdy,

On our customers servers, both backtraces involve a signal to gracefully
restart interrupting Apache while it is processing the configuration file in
various places.

We've been able to replicate this when gracefully restarting under mpm_worker
multiple times in a row with an extremely large httpd configuration (10k-20k
vhosts+).

I hope this helps!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60487] Core dumps in mpm_event during graceful restart

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60487

--- Comment #5 from Jeff Wheelhouse  ---
Jacob, is it alright if I contact you directly to discuss the issues you're
seeing?  We're having two restart-related segfault problems, this is one and we
haven't reported the other yet due to insufficient information -- it's much
squirrelier.

>From what you describe, I have a hunch you're also seeing the other problem,
and I'd like to compare notes without derailing this report if (as I suspect)
it turns out to be a second, unrelated issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

[Bug 60487] Core dumps in mpm_event during graceful restart

2017-02-16 Thread bugzilla 
https://bz.apache.org/bugzilla/show_bug.cgi?id=60487

--- Comment #7 from Yann Ylavic  ---
(In reply to Eric Covener from comment #2)
> 
> Maybe a good sanity check would be to look
> for mpm_state == AP_MPMQ_STARTING when retained == NULL and no-op'ing it
> altogether.  An even safer option might be to only handle the graceful
> flavors w/ the new block, to avoid the chance a hard stop or hard restart is
> ignored if we're missing something?

I think we should avoid touching anything scoped/static to the mpm module (dso)
in a signal handler, otherwise any signal delivered while the module is
unloaded might raise the fault.

That is: mpm_state, shutdown_pending, restart_pending and retained.

How about allocating them (in a struct) from ap_pglobal?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org