Re: PHP5.3.6
On Sat, Apr 16, 2011 at 8:54 PM, Akins, Brian brian.ak...@turner.com wrote: On 4/15/11 6:11 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2011 23:01, schrieb Jeff Trawick: FastCGI is a way to get us out of all sorts of dark alleys; let's be sure to keep it in mind as one of the tools to address binary compatibility issues, PHP-centered or not but you can not use .htaccess with cgi .htaccess works just fine with FastCGI. .htaccess is handled by Apache as normal. FastCGI is just a different way to run the PHP interpreter in this case. No, php's directive does not work when PHP is used via FastCGI. But the .user.ini feature in 5.3 (ported from pecl's htscanner) does. Also I disagree that FastCGI is the best thing on earth for php/other on windows. But that's another story :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
RE: Cannot build httpd on Win 7 + VS2010
I also tried the method suggested by http://www.blackdot.be/?inc=apache/knowledge/tutorials/x64 that uses perl cvtdsp.pl -2005 to first make VS2005 project files, but all the *.vcproj files cannot converted to VS2010. Does anybody know the reason? (VS2008 had no problem, though.) Regards, Bing -Original Message- From: Gabriel Petrovay [mailto:gabipetro...@gmail.com] Sent: Wednesday, October 27, 2010 4:56 AM To: dev@httpd.apache.org Subject: Re: Cannot build httpd on Win 7 + VS2010 I am still experimenting. I don't think it's a permission problem. I am on a separate partition with all the necessary rights. I managed though to build it with nmake only with the click one more time approach. So, by running nmake (NMAKE /f Makefile.win installd) several times I managed to get over the 'tempfile.bat' errors. Does this ring a bell? In VS, they are errors. Trying to built according to: http://httpd.apache.org/docs/2.2/platform/win_compiling.html#workspacebuild - during the first build, I got header not found errors complaining about apr.h - (I tried one more time) starting from the 2nd build onwards, the errors are LINK errors. cannot find external symbol With the nmake build above i could finally build/debug the problem mentioned in the other post (slow shutdown waiting for treads) (I see that you already replied to that, and I am curious ;) ) Regards, Gabriel On Tue, Oct 26, 2010 at 10:41 PM, Gregg L. Smith li...@glewis.com wrote: Hello Gabriel, I've run into this on xp, vista 2008. Somehow source folders get put in read only mode. Make them writable again and it will build. On Win7 if that means putting it in Documents, so be it. As far as errors in IDE, you sure they are not warnings? 2 warnings per project is what I see on 2010. I do not like 2010 so I haven't compiled Apache with since I gave it a try after it's release. Gregg Original Message --- Hi, Can you make Apache build on Windonws 7 and Visual Studio 2010? Neither the nmake nor the IDE builds work: NMAKE: nmake -f Makefile.win installd Error: aprutil.mak(1459) : fatal error U1054: cannot create inline file 'tempfile.bat' IDE: building project InstallBin = thousands of errors Are these build scripts/project maintained? Thanks! -- MSc Gabriel Petrovay Mobile: +41(0)787978034 www.28msec.com -- MSc Gabriel Petrovay Mobile: +41(0)787978034 www.28msec.com
Re: SSL related DoS
On Sat, 16 Apr 2011, Eric Covener wrote: would mod_reqtimeout step in after too many renegotiations had eaten too much wall time? Whenever mod_ssl reads data from the client, mod_reqtimeout will check the configured timeouts. It is possible that the data sent during reneg may prevent the minimum required data rate feature from triggering, but maximum timeouts will always be enforced. The attacker can just create new connections, though.
Re: SSL related DoS
On Sat, Apr 16, 2011 at 3:39 PM, Daniel Ruggeri drugg...@primary.net wrote:
On 4/16/2011 11:52 AM, Chris Hill wrote:
Dear Apache httpd dev list,
...
The reason why I insist in this is that the world has come to depend on
HTTP/SOAP over SSL (and Apache/OpenSSL are probably the most popular
implementation) for business critical apps, yet, it is not clear how
these businesses can play around with configuration parameters to fine
tune these SSL settings to their specific needs, e.g. *ensure client
side renegs can be disabled* or at least,*provide a way of limiting how
many of these a client initiated re-negotiations (or initial handshakes)
a server will allow per second for a specific connection/IP*. It is
great that recent Apache builds disable client initiated renegotiation
by default, but how can I ensure this will never be turned back on in
future releases given the lack of configuration parameters?
Chris;
I believe this topic (enable/disable renegotiation) was brought up on this
list just a matter of days ago. I don't recall seeing a consensus, but I
would agree that a configuration parameter to (dis)allow client-initiated
renegotiation would be a Very Good Thing. I don't think this would be very
difficult to implement - and would be a good start to correct the issues you
call out.
I thought client-initiated renegotiation was already disabled out of
the box, with no configuration mechanism to re-enable.
From ssl_engine_kernel.c, 2.2.x-latest:
/* If the first handshake is complete, change state to reject any
* subsequent client-initated renegotiation. */
else if ((where SSL_CB_HANDSHAKE_DONE) scr-reneg_state ==
RENEG_INIT) {
scr-reneg_state = RENEG_REJECT;
}
[PATCH] check_forensic re tweak
With mod_unique_id installed there's the possibility of having a - in the forensic id, so here's a minor patch to ensure check_forensic does the right thing. Index: support/check_forensic === --- support/check_forensic(revision 1094142) +++ support/check_forensic(working copy) @@ -43,8 +43,8 @@ trap rm -f -- \$all\ \$in\ \$out\; 0 1 2 3 13 15 cut -f 1 -d '|' $F $all -grep + $all | cut -c2- | sort $in -grep -- - $all | cut -c2- | sort $out +grep ^+ $all | cut -c2- | sort $in +grep -- ^- $all | cut -c2- | sort $out # use -i instead of -I for GNU xargs join -v 1 $in $out | xargs -I xx egrep ^\\+xx $F
mod_fcgid can kill all the services on the server via kill -15 -1
Hello,
There is a very interesting, and quite a rare bug in mod_fcgid. It is easy
to reproduce if you can cause fork to fail (which can be done with
CloudLinux -- if anyone wants to replicate it).
*Here is how it works: *
mod_fcgid tries to spawn a new process (proc_spawn_process in
fcgid_proc_unix.c), but fork returns -1.
More exactly fcgid_create_privileged_process function call returns error,
and fills in tmpproc.pid with -1 tmpproc is assiged to procnode-proc_id).
Now, if at the same time service httpd restart is executed, function
kill_all_subprocess in fcgid_pm_main.c will execute, and it will try to go
through all procnodes, sending SIGTERM via proc_kill_gracefully, (and then
SIGKILL via proc_kill_force) to procnode-proc_id.pid
Yet, one procnode will be pointing to procnode-proc_id.pid, causing kill
-15 -1 (kill all).
The end results all services on the server failing, including SSH, apache,
syslogd, etc..
I guess the problem is really rare for most people. Also it is quite hard to
diagnose, as it is completely not clear where the signal came from, and it
took us some time to correlate them with apache restarts.. Yet due to our OS
being used by shared hosts (where httpd restart is common thing), and our
ability to limit memory available to processes on per virtual host bases
(which causes fork to fail once that virtual host reaches memory limit), we
see the issue quite often.
The solution is quite simple (not sure if it is the best / right solution),
in file: fcgid_proc_unix.c, in methods proc_kill_gracefully, line:
rv = apr_proc_kill((procnode-proc_id), SIGTERM);
should be changed to:
if (procnode-proc_id.pid != -1) {
rv = apr_proc_kill((procnode-proc_id), SIGTERM);
} else {
rv = APR_SUCCESS;
}
Similarly in proc_kill_force
rv = apr_proc_kill((procnode-proc_id), SIGKILL);
should be changed to:
if (procnode-proc_id.pid != -1) {
rv = apr_proc_kill((procnode-proc_id), SIGKILL);
} else {
rv = APR_SUCCESS;
}
Regards,
Igor Seletskiy
CEO @ Cloud Linux Inc
Is this a test framework bug?
Hi, t/modules/proxy.t of the test framework contains at line 32 the following 2 tests: $r = GET(/reverse/modules/cgi/nph-102.pl); ok t_cmp($r-code, 200, reverse proxy to nph-102); ok t_cmp($r-content, this is nph-stdout, reverse proxy 102 response); The test fails here and I think the test is wrong. When accessed via socat I see this output: echo -e 'GET /reverse/modules/cgi/nph-102.pl HTTP/1.1\r\nHost: localhost:8538\r\n\r' | socat stdio tcp:localhost.localdomain:8538 HTTP/1.1 102 Please Wait... Host: nph-102 HTTP/1.1 200 OK Date: Sun, 17 Apr 2011 15:30:30 GMT Server: Apache/2.3.12-dev (Unix) mod_ssl/2.3.12-dev OpenSSL/1.0.0 DAV/2 Content-Type: text/plain Transfer-Encoding: chunked 12 this is nph-stdout 0 I believe this is what is to be expected. But the test above tests for status 200 only. So, it will succeed if the proxy module eats up the 102 message. This may be a problem with my libwww-perl. LWP has recently experienced a major release upgrade. It reports $r-code as 102. Perhaps older versions report the 2nd response only. Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
httpd-framework: a few forgotten need_module()s
Hi,
t/apache/if_sections.t needs the proxy module, t/modules/filter.t needs
mod_case_filter.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Index: t/apache/if_sections.t
===
--- t/apache/if_sections.t (revision 1094143)
+++ t/apache/if_sections.t (working copy)
@@ -12,6 +12,7 @@
plan tests = 11*2,
need need_lwp,
need_module('mod_headers'),
+ need_module('mod_proxy'),
need_min_apache_version('2.3.8');
Index: t/modules/filter.t
===
--- t/modules/filter.t (revision 1094143)
+++ t/modules/filter.t (working copy)
@@ -6,7 +6,7 @@
use Apache::TestUtil qw(t_cmp t_write_file);
use File::Spec;
-plan tests = 1, need need_module('mod_filter');
+plan tests = 1, need need_module('mod_filter'), need_module('mod_case_filter');
my $r = GET_BODY('/modules/cgi/xother.pl');
Re: ap_read_config in 2.3.11
On Tuesday, April 12, 2011 18:24:28 William A. Rowe Jr. wrote:
Suggestion - an EXEC_ON_READ 'DynamicModulesMax' directive, which would
let us conf_vector_length = total_modules + dyn_modules_max; after the
read_config, and finally lock down conf_vector_length = total_modules;
at the end of post_config. WDYT?
The attached patch implements the DynamicModulesMax directive. It can appear
anywhere in the config file but is best placed *before* any LoadModule
directive. Up to post_config the number of prelinked modules plus
DynamicModulesMax is used as conf_vector_length. In core_post_config the
length is then settled on total_modules.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Index: server/config.c
===
--- server/config.c (revision 1094174)
+++ server/config.c (working copy)
@@ -181,22 +181,22 @@
static int total_modules = 0;
/* dynamic_modules is the number of modules that have been added
- * after the pre-loaded ones have been set up. It shouldn't be larger
- * than DYNAMIC_MODULE_LIMIT.
+ * after the pre-loaded ones have been set up. It should be at most
+ * dynamic_modules_max.
*/
static int dynamic_modules = 0;
-/* The maximum possible value for total_modules, i.e. number of static
- * modules plus DYNAMIC_MODULE_LIMIT.
+/* The maximum possible value for dynamic_modules. Shouldn't be larger than
+ * DYNAMIC_MODULE_LIMIT.
*/
-static int max_modules = 0;
+static int dynamic_modules_max;
/* The number of elements we need to alloc for config vectors. Before loading
- * of dynamic modules, we must be liberal and set this to max_modules. After
- * loading of dynamic modules, we can trim it down to total_modules. On
- * restart, reset to max_modules.
+ * of dynamic modules, we must be liberal and set this to the largest possible
+ * value (number of prelinked modules + dynamic_modules_max). After loading of
+ * dynamic modules, we can trim it down to total_modules.
*/
-static int conf_vector_length = 0;
+static int conf_vector_length;
AP_DECLARE_DATA module *ap_top_module = NULL;
AP_DECLARE_DATA module **ap_loaded_modules=NULL;
@@ -234,6 +234,22 @@
* overridden).
*/
+AP_DECLARE(void) ap_set_dynamic_modules_max(int lim)
+{
+dynamic_modules_max = lim;
+conf_vector_length = dynamic_modules_max + total_modules - dynamic_modules;
+}
+
+AP_DECLARE(int) ap_get_dynamic_modules_max(void)
+{
+return dynamic_modules_max;
+}
+
+AP_DECLARE(void) ap_settle_module_count(void)
+{
+conf_vector_length = total_modules;
+}
+
static ap_conf_vector_t *create_empty_config(apr_pool_t *p)
{
void *conf_vector = apr_pcalloc(p, sizeof(void *) * conf_vector_length);
@@ -542,7 +558,7 @@
}
if (m-module_index == -1) {
-if (dynamic_modules = DYNAMIC_MODULE_LIMIT) {
+if (dynamic_modules = dynamic_modules_max) {
return apr_psprintf(p, Module \%s\ could not be loaded,
because the dynamic module limit was
reached. Please increase
@@ -740,8 +756,7 @@
for (m = ap_preloaded_modules; *m != NULL; m++)
(*m)-module_index = total_modules++;
-max_modules = total_modules + DYNAMIC_MODULE_LIMIT + 1;
-conf_vector_length = max_modules;
+ap_set_dynamic_modules_max(DYNAMIC_MODULE_LIMIT);
/*
* Initialise list of loaded modules and short names
@@ -2255,12 +2270,6 @@
}
-static apr_status_t reset_conf_vector_length(void *dummy)
-{
-conf_vector_length = max_modules;
-return APR_SUCCESS;
-}
-
AP_DECLARE(server_rec*) ap_read_config(process_rec *process, apr_pool_t *ptemp,
const char *filename,
ap_directive_t **conftree)
@@ -2272,6 +2281,7 @@
return s;
}
+ap_set_dynamic_modules_max(DYNAMIC_MODULE_LIMIT);
init_config_globals(p);
/* All server-wide config files now have the SAME syntax... */
@@ -2309,14 +2319,6 @@
return NULL;
}
-/*
- * We have loaded the dynamic modules. From now on we know exactly how
- * long the config vectors need to be.
- */
-conf_vector_length = total_modules;
-apr_pool_cleanup_register(p, NULL, reset_conf_vector_length,
- apr_pool_cleanup_null);
-
error = process_command_config(s, ap_server_post_read_config, conftree,
p, ptemp);
Index: server/core.c
===
--- server/core.c (revision 1094174)
+++ server/core.c (working copy)
@@ -3167,6 +3167,19 @@
}
#endif
+static const char *set_dynamic_modules_max(cmd_parms *cmd, void *dummy,
+ const char *arg)
+{
+const char *err = ap_check_cmd_context(cmd, NOT_IN_DIR_LOC_FILE);
+
+if (err != NULL) {
+return err;
+}
+
+
Re: SSL related DoS
Yes, disabled by default now. My point was just make sure it did not come
back again, at least not without a config parameter to easily
disable/enable.
On Sun, Apr 17, 2011 at 8:41 AM, Jeff Trawick traw...@gmail.com wrote:
On Sat, Apr 16, 2011 at 3:39 PM, Daniel Ruggeri drugg...@primary.net
wrote:
On 4/16/2011 11:52 AM, Chris Hill wrote:
Dear Apache httpd dev list,
...
The reason why I insist in this is that the world has come to depend on
HTTP/SOAP over SSL (and Apache/OpenSSL are probably the most popular
implementation) for business critical apps, yet, it is not clear how
these businesses can play around with configuration parameters to fine
tune these SSL settings to their specific needs, e.g. *ensure client
side renegs can be disabled* or at least,*provide a way of limiting how
many of these a client initiated re-negotiations (or initial handshakes)
a server will allow per second for a specific connection/IP*. It is
great that recent Apache builds disable client initiated renegotiation
by default, but how can I ensure this will never be turned back on in
future releases given the lack of configuration parameters?
Chris;
I believe this topic (enable/disable renegotiation) was brought up on
this
list just a matter of days ago. I don't recall seeing a consensus, but I
would agree that a configuration parameter to (dis)allow client-initiated
renegotiation would be a Very Good Thing. I don't think this would be
very
difficult to implement - and would be a good start to correct the issues
you
call out.
I thought client-initiated renegotiation was already disabled out of
the box, with no configuration mechanism to re-enable.
From ssl_engine_kernel.c, 2.2.x-latest:
/* If the first handshake is complete, change state to reject any
* subsequent client-initated renegotiation. */
else if ((where SSL_CB_HANDSHAKE_DONE) scr-reneg_state ==
RENEG_INIT) {
scr-reneg_state = RENEG_REJECT;
}
Re: SSL related DoS
Bill, that is already good, but then the question still remains of whether there is something that can be done disable/control/detect too many handshakes from any given client (new or renegotiated). I'd love to understand whether this is even a reasonable thing discuss, as I do not have knowledge of the Internals of Apache/OpenSSL. On Saturday, April 16, 2011, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 4/16/2011 2:39 PM, Daniel Ruggeri wrote: On 4/16/2011 11:52 AM, Chris Hill wrote: but how can I ensure this will never be turned back on in future releases given the lack of configuration parameters? Chris; I believe this topic (enable/disable renegotiation) was brought up on this list just a matter of days ago. I don't recall seeing a consensus, but I would agree that a configuration parameter to (dis)allow client-initiated renegotiation would be a Very Good Thing. I don't think this would be very difficult to implement - and would be a good start to correct the issues you call out. One, there are no assurances. But today, renegotiation will not work out of the box *without* SSLInsecureRenegotation... The group consensus seems to be that introducing 'new' safe client renegotiation will come at the cost of a new directive to -enable- it, leaving it disabled, by default. The group seems to generally doubt that there is any DoS (SSL is resource intensive, new connections and renegotiated connections are equally so), but there doesn't seem to be any immediate demand for renegotiation support, so it makes the most sense to leave it optional-to-enable rather than optional-to-disable.
Re: svn commit: r1094174 - in /httpd/httpd: branches/2.2.x/CHANGES branches/2.2.x/STATUS branches/2.2.x/modules/arch/win32/mod_win32.c trunk/CHANGES
Am 17.04.2011 18:38, schrieb fua...@apache.org: Author: fuankg Date: Sun Apr 17 16:38:42 2011 New Revision: 1094174 URL: http://svn.apache.org/viewvc?rev=1094174view=rev Log: Added shebang check for '! so that .vbs scripts can work as CGI. Backport of r1054347 from trunk; reviewed by wrowe, trawick. Modified: httpd/httpd/branches/2.2.x/CHANGES httpd/httpd/branches/2.2.x/STATUS httpd/httpd/branches/2.2.x/modules/arch/win32/mod_win32.c httpd/httpd/trunk/CHANGES Modified: httpd/httpd/branches/2.2.x/CHANGES URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/CHANGES?rev=1094174r1=1094173r2=1094174view=diff == --- httpd/httpd/branches/2.2.x/CHANGES [utf-8] (original) +++ httpd/httpd/branches/2.2.x/CHANGES [utf-8] Sun Apr 17 16:38:42 2011 @@ -1,6 +1,10 @@ -*- coding: utf-8 -*- Changes with Apache 2.2.18 + *) mod_win32: Added shebang check for '! so that .vbs scripts can work as CGI. + Win32's cscript interpreter can only use a single quote as comment char. + [Guenter Knauf] + *) configure: Fix htpasswd/htdbm libcrypt link errors with some newer linkers. [Stefan Fritsch] Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=1094174r1=1094173r2=1094174view=diff == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Sun Apr 17 16:38:42 2011 @@ -91,13 +91,6 @@ RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] - * mod_win32: Add shebang check so that .vbs scripts can work as CGI. - Trunk patch: http://svn.apache.org/viewvc?view=revisionrevision=1054347 - 2.2.x patch: Trunk version of patch works with offset - +1 fuankg, wrowe, trawick - wrowe notes: CHANGES needs to be clearer than the text above. - Trunk/CHANGES and 2.2.x/CHANGES need an update. please check if the CHANGES entry is sufficient or suggest a better wording ... Some samples to test the new feature here: http://people.apache.org/~fuankg/vbscripts/ Gün.
[PATCH] Add TLS-SRP (RFC 5054) support to mod_ssl
Posted at: https://issues.apache.org/bugzilla/show_bug.cgi?id=51075 TLS-SRP (RFC 5054)[1] is an implementation of the Secure Remote Password (SRP)[2] protocol as a key exchange method for TLS. It uses a shared secret derived from a user's password to supplement or replace third-party certificates in authenticating a TLS connection. This patch adds TLS-SRP support to mod_ssl, adds two new directives (SSLSRPVerifierFile and SSLSRPUnknownUserSeed), adds two new SSL env vars (SSL_SRP_USER and SSL_SRP_USERINFO), and includes basic documentation. The TLS-SRP-specific code uses preprocessor guards on OPENSSL_NO_SRP and is enabled only if OpenSSL = 1.0.1, which is the first version of OpenSSL that will include SRP support[3]. To use this patch: (1) install OpenSSL 1.0.1; (2) create an OpenSSL SRP verifier (passwd) file with `openssl srp -srpvfile passwd.srpv -add username`; (3) specify this file in the server config with: SSLSRPVerifierFile /path/to/passwd.srpv (4) optionally, for easier testing, force the use of SRP: SSLCipherSuite !DSS:!aRSA:SRP To test the TLS-SRP functionality, use gnutls-cli or a version of cURL with TLS-SRP support: gnutls-cli --srpusername user --srppasswd secret host curl --tlsuser user --tlspassword secret -k https://host TLS-SRP support for Apache is already provided by mod_gnutls[4]. Now that PAKE patents have expired and the security of CAs is increasingly being doubted, TLS-SRP is gaining wider acceptance. GnuTLS, mod_gnutls, and TLSLite have supported it for years; cURL since February; OpenSSL will support it in the next release; and I have also assembled patches[5] for Chrome, Firefox, and NSS. This patch was originally created by Christophe Renou and Peter Sylvester of EdelWeb. I updated it to work with Apache 2's mod_ssl. Bugzilla entry: https://issues.apache.org/bugzilla/show_bug.cgi?id=51075 Patch: https://issues.apache.org/bugzilla/attachment.cgi?id=26892 [1] http://tools.ietf.org/html/rfc5054 [2] http://srp.stanford.edu/ [3] http://cvs.openssl.org/chngview?cn=20484 [4] http://trustedhttp.org/wiki/TLS-SRP_in_Apache_mod_gnutls [5] http://trustedhttp.org/
Re: [PATCH] Add TLS-SRP (RFC 5054) support to mod_ssl
This is excellent news! On Apr 17, 2011 5:48 PM, Quinn Slack s...@cs.stanford.edu wrote: Posted at: https://issues.apache.org/bugzilla/show_bug.cgi?id=51075 TLS-SRP (RFC 5054)[1] is an implementation of the Secure Remote Password (SRP)[2] protocol as a key exchange method for TLS. It uses a shared secret derived from a user's password to supplement or replace third-party certificates in authenticating a TLS connection. This patch adds TLS-SRP support to mod_ssl, adds two new directives (SSLSRPVerifierFile and SSLSRPUnknownUserSeed), adds two new SSL env vars (SSL_SRP_USER and SSL_SRP_USERINFO), and includes basic documentation. The TLS-SRP-specific code uses preprocessor guards on OPENSSL_NO_SRP and is enabled only if OpenSSL = 1.0.1, which is the first version of OpenSSL that will include SRP support[3]. To use this patch: (1) install OpenSSL 1.0.1; (2) create an OpenSSL SRP verifier (passwd) file with `openssl srp -srpvfile passwd.srpv -add username`; (3) specify this file in the server config with: SSLSRPVerifierFile /path/to/passwd.srpv (4) optionally, for easier testing, force the use of SRP: SSLCipherSuite !DSS:!aRSA:SRP To test the TLS-SRP functionality, use gnutls-cli or a version of cURL with TLS-SRP support: gnutls-cli --srpusername user --srppasswd secret host curl --tlsuser user --tlspassword secret -k https://host TLS-SRP support for Apache is already provided by mod_gnutls[4]. Now that PAKE patents have expired and the security of CAs is increasingly being doubted, TLS-SRP is gaining wider acceptance. GnuTLS, mod_gnutls, and TLSLite have supported it for years; cURL since February; OpenSSL will support it in the next release; and I have also assembled patches[5] for Chrome, Firefox, and NSS. This patch was originally created by Christophe Renou and Peter Sylvester of EdelWeb. I updated it to work with Apache 2's mod_ssl. Bugzilla entry: https://issues.apache.org/bugzilla/show_bug.cgi?id=51075 Patch: https://issues.apache.org/bugzilla/attachment.cgi?id=26892 [1] http://tools.ietf.org/html/rfc5054 [2] http://srp.stanford.edu/ [3] http://cvs.openssl.org/chngview?cn=20484 [4] http://trustedhttp.org/wiki/TLS-SRP_in_Apache_mod_gnutls [5] http://trustedhttp.org/
Re: mod_fcgid can kill all the services on the server via kill -15 -1
Hi, all
Another question, does proc_wait_process() should update procnode-proc_id to 0
too? or else mod_fcgid may send a signal to another irrelevant process while
apache is shutting down? I don't follow up mod_fcgid for a while, I just took a
glance, maybe it's updated somewhere else?
By the way, procnode-proc_id is set to 0 while apache startup, so why not
update procnode-proc_id to 0 while fcgid_create_privileged_process() is fail?
And then check magic number 0 rather than both -1 and 0, in both
proc_kill_gracefully() and proc_kill_force().
Cheers.
Ryan
Hello,
There is a very interesting, and quite a rare bug in mod_fcgid. It is easy to
reproduce if you can cause fork to fail (which can be done with CloudLinux --
if anyone wants to replicate it).
Here is how it works:
mod_fcgid tries to spawn a new process (proc_spawn_process in
fcgid_proc_unix.c), but fork returns -1.
More exactly fcgid_create_privileged_process function call returns error, and
fills in tmpproc.pid with -1 tmpproc is assiged to procnode-proc_id).
Now, if at the same time service httpd restart is executed, function
kill_all_subprocess in fcgid_pm_main.c will execute, and it will try to go
through all procnodes, sending SIGTERM via proc_kill_gracefully, (and then
SIGKILL via proc_kill_force) to procnode-proc_id.pid
Yet, one procnode will be pointing to procnode-proc_id.pid, causing kill -15
-1 (kill all).
The end results all services on the server failing, including SSH, apache,
syslogd, etc..
I guess the problem is really rare for most people. Also it is quite hard to
diagnose, as it is completely not clear where the signal came from, and it took
us some time to correlate them with apache restarts.. Yet due to our OS being
used by shared hosts (where httpd restart is common thing), and our ability to
limit memory available to processes on per virtual host bases (which causes
fork to fail once that virtual host reaches memory limit), we see the issue
quite often.
The solution is quite simple (not sure if it is the best / right solution), in
file: fcgid_proc_unix.c, in methods proc_kill_gracefully, line:
rv = apr_proc_kill((procnode-proc_id), SIGTERM);
should be changed to:
if (procnode-proc_id.pid != -1) {
rv = apr_proc_kill((procnode-proc_id), SIGTERM);
} else {
rv = APR_SUCCESS;
}
Similarly in proc_kill_force
rv = apr_proc_kill((procnode-proc_id), SIGKILL);
should be changed to:
if (procnode-proc_id.pid != -1) {
rv = apr_proc_kill((procnode-proc_id), SIGKILL);
} else {
rv = APR_SUCCESS;
}
Regards,
Igor Seletskiy
CEO @ Cloud Linux Inc
