You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@apr.apache.org by bu...@apache.org on 2018/01/10 08:12:57 UTC
[Bug 61985] New: Incorrect time-out blocking dropped connection
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
Bug ID: 61985
Summary: Incorrect time-out blocking dropped connection
Product: APR
Version: HEAD
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: APR
Assignee: bugs@apr.apache.org
Reporter: marc.stern@approach.be
Target Milestone: ---
In support/unix/waitio.c, in case pfd.fd < 0, the poll() function waits until
the time-out is expired.
This problem happens when, for instance, ModSecurity drops a connection in
httpd. In this case, ressources gets blocked until the timeout expires.
In this situation, we should immediately return an error.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 61985] Incorrect time-out blocking dropped connection
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
Yann Ylavic <yl...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #2 from Yann Ylavic <yl...@gmail.com> ---
The man of poll(2) on linux says:
"The field fd contains a file descriptor for an open file. If this
field is negative, then the corresponding events field is ignored and the
revents field returns zero. (This provides an easy way of ignoring a file
descriptor for a single poll() call: simply negate the fd field...)"
So it's valid operation somehow (which timeouts), why wouldn't APR respect
that?
I'm not sure apr_wait_for_io_or_timeout() should error here, not really a
strong opinion either.
Maybe something to fix on the caller side though, how does such negative fd
come here, double close? No c->aborted on the httpd side?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 61985] Incorrect time-out blocking dropped connection
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
--- Comment #8 from Yann Ylavic <yl...@gmail.com> ---
From my POV, the drawback of defensive programming (which we usually don't do
in APR) is that the error/fault finally happens at the wrong/later place, and
thus becomes hard to debug. For instance, we don't check for NULL args where
they shouldn't be (e.g. given by the responsible user), and prefer to crash
where is due.
Here it may make sense to error on an invalid fd though, it's the single one to
be poll()ed after all, so there is really nothing to wait for. Let's see what
others say.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 61985] Incorrect time-out blocking dropped connection
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
--- Comment #5 from Yann Ylavic <yl...@gmail.com> ---
I see but why doesn't the "phase 1" return an error for httpd to stop
processing/handling the connection?
No close (nor c->aborted) needed on the mod_security side then, I think httpd
would take care of the best way to close the connection ASAP in this case (in
cluding TLS close notify and so on if needed...).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 61985] Incorrect time-out blocking dropped connection
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
--- Comment #4 from Marc Stern <ma...@approach.be> ---
Note that the patch actually proves to solve the problem
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 61985] Incorrect time-out blocking dropped connection
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
--- Comment #6 from Yann Ylavic <yl...@gmail.com> ---
By the way, did you follow bug 61551 ?
mod_security could possibly improve the way it returns to httpd in some phases,
maybe we could discuss this on dev@httpd, your call.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 61985] Incorrect time-out blocking dropped connection
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
--- Comment #7 from Marc Stern <ma...@approach.be> ---
I didn't follow bug 61551. I just had a look at it but I have to admit that I
don't understand the internals well enough to check if this would solve the
problem.
You may be right (and youprobably are) that ModSecurity doesn't behave
correctly, but the "sanity" check I propose is, imho, a good practice
(defensive programming). It costs no resource, doesn't complexify the code and
protects the code from unexpected situations (due to a misbehaved module or
maybe other causes), so it offers, at least, a stability "insurance".
I don't see any drawback to it, only an advantage (that should be very small in
an ideal world, I agree).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 61985] Incorrect time-out blocking dropped connection
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
Marc Stern <ma...@approach.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marc.stern@approach.be
--- Comment #1 from Marc Stern <ma...@approach.be> ---
Created attachment 35666
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35666&action=edit
patch
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org
[Bug 61985] Incorrect time-out blocking dropped connection
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61985
Marc Stern <ma...@approach.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #3 from Marc Stern <ma...@approach.be> ---
When a ModSecurity rule decides a drop in phase 1, the TCP is immediately
closed (which is good and intended), however the handler behind is still
somehow called. If this handler is "proxy-server", it will stay stuck until the
global request timeout (5mn) shuts it down.
This has the nasty side-effect of keeping an httpd thread of process busy all
that time.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org