Re: *Match, RewriteRule POLA violation?
On Thu, 30 Apr 2015, Yann Ylavic wrote:
On Thu, Apr 30, 2015 at 2:57 PM, Jim Riggs apache-li...@riggs.me wrote:
Thanks, Yann. I remember looking at this code before. The question remains, though: Is it
currently wrong?
Does it need to be fixed, or was this distinction made intentionally?
Is there a specific use case that requires the regex-matching directives to not
get slash-normalized URIs?
I would like it to be fixed, non leading /+ is equivalent to /,
this would break very few (if any) cases IMHO, and may even unbreak
more ones .
+1
I would expect Location and LocationMatch using the same uri for
comparison. I would actually go so far as the current state might
warrant a CVE for being a hidden security risk that might cause
inadvertent information exposure.
If someone really wants to have the raw uri for some reason I guess
they can use If and a suitable expr?
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | ni...@acc.umu.se
---
I! finally! learned! to! punctuate! Kirk's! sentences!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: *Match, RewriteRule POLA violation?
* Niklas Edmundsson wrote: On Thu, 30 Apr 2015, Yann Ylavic wrote: On Thu, Apr 30, 2015 at 2:57 PM, Jim Riggs apache-li...@riggs.me wrote: Thanks, Yann. I remember looking at this code before. The question remains, though: Is it currently wrong? Does it need to be fixed, or was this distinction made intentionally? Is there a specific use case that requires the regex-matching directives to not get slash-normalized URIs? I would like it to be fixed, non leading /+ is equivalent to /, this would break very few (if any) cases IMHO, and may even unbreak more ones . +1 I would expect Location and LocationMatch using the same uri for comparison. Hmm, that assumption is wrong by definition. Location always matches a prefix (a part of a parsed/unparsed url), while LocationMatch always matches the complete URL. I would actually go so far as the current state might warrant a CVE for being a hidden security risk that might cause inadvertent information exposure. It *is* documented right here, btw: http://httpd.apache.org/docs/2.4/mod/core.html#location (found it, eventually...) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2
Re: Best practice for handling synchronous signals SIGFPE etc
Great information, thanks all! -Mark On Mon, Apr 20, 2015 at 6:15 PM, Sorin Manolache sor...@gmail.com wrote: On 2015-04-20 21:50, Mark Taylor wrote: I found that ./server/mpm_unix.c is registering a handler (sig_coredump) for SIGFPE, SIGSEGV, and other synchronous signals. I'd like to handle at least these two in my module, using my own handler. But then how do I determine if the the handler is called on a request thread or a server thread? And I'd like to default to still run the sig_coredump() function if it's signal is not in my module. Have a look at the man-page of sigaction and getcontext. When you set a signal handler you get the old signal handler (3rd argument of sigaction). So you can store it in a variable. In your own signal handler you do want you intend to do and at the end you call the old signal handler. In this way you can call sig_coredump. However you have to make sure that you set your signal handler _after_ apache has set his. Otherwise apache will replace yours. Have a look at the siginfo_t structure that is passed by the OS to your handler. You can get the program ID and the user ID from that structure. But not the thread apparently. Anyway, at least you can determine if the signal was raised in the parent or one of the worker children. Look also at the ucontext structure (man getcontext) that is passed to your signal handler. Maybe you can determine the source of the signal from that structure, though I think it's too close to machine code and registers to be useful. Alternately, you could use a thread-local variable ( https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Thread-Local.html). The first thing you do when you enter each function of your module is to set the variable. Whenever you exit a function you reset it. Thus, you may determine in your signal handler by inspection of the variable if the signal was raised by your module. (This works only if the signal handler is executed in the thread where the signal was raised which is not always the case. Otherwise you'll set some variable in your thread and read another one in the handler. Here's some information: http://stackoverflow.com/questions/11679568/signal-handling-with-multiple-threads-in-linux. Apparently the handlers for SIGSEGV and SIGFPE are called in the thread that raised them but it's not clear.) Sorin
mod_ssl: inline SSL_X509_INFO_load_path(); please review
I believe SSL_X509_INFO_load_path() should be inlined into
its only caller. I'd like some eyes on this change since
it's not just mechanical.
The desired behaviour seems to be load as many certs as possible
from a directory, looping over its file entries. Ignore errors,
e.g. in case the file is not a cert. The replaced function returned
a boolean which was never checked.
Regarding the removed comment about merging the dir-read loop
with another one: I don't think that's worth it.
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1677159)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -1247,7 +1247,26 @@ static apr_status_t ssl_init_proxy_certs(server_re
}
if (pkp-cert_path) {
-SSL_X509_INFO_load_path(ptemp, sk, pkp-cert_path);
+apr_dir_t *dir;
+apr_finfo_t dirent;
+apr_int32_t finfo_flags = APR_FINFO_TYPE|APR_FINFO_NAME;
+
+if (apr_dir_open(dir, pkp-cert_path, ptemp) == APR_SUCCESS) {
+while ((apr_dir_read(dirent, finfo_flags, dir)) == APR_SUCCESS) {
+const char *fullname;
+
+if (dirent.filetype == APR_DIR) {
+continue; /* don't try to load directories */
+}
+
+fullname = apr_pstrcat(ptemp,
+ pkp-cert_path, /, dirent.name,
+ NULL);
+modssl_X509_INFO_load_file(ptemp, sk, fullname);
+}
+
+apr_dir_close(dir);
+}
}
if ((ncerts = sk_X509_INFO_num(sk)) = 0) {
Index: modules/ssl/ssl_util_ssl.c
===
--- modules/ssl/ssl_util_ssl.c (revision 1677159)
+++ modules/ssl/ssl_util_ssl.c (working copy)
@@ -441,43 +441,6 @@ BOOL modssl_X509_INFO_load_file(apr_pool_t *ptemp,
return TRUE;
}
-BOOL SSL_X509_INFO_load_path(apr_pool_t *ptemp,
- STACK_OF(X509_INFO) *sk,
- const char *pathname)
-{
-/* XXX: this dir read code is exactly the same as that in
- * ssl_engine_init.c, only the call to handle the fullname is different,
- * should fold the duplication.
- */
-apr_dir_t *dir;
-apr_finfo_t dirent;
-apr_int32_t finfo_flags = APR_FINFO_TYPE|APR_FINFO_NAME;
-const char *fullname;
-BOOL ok = FALSE;
-
-if (apr_dir_open(dir, pathname, ptemp) != APR_SUCCESS) {
-return FALSE;
-}
-
-while ((apr_dir_read(dirent, finfo_flags, dir)) == APR_SUCCESS) {
-if (dirent.filetype == APR_DIR) {
-continue; /* don't try to load directories */
-}
-
-fullname = apr_pstrcat(ptemp,
- pathname, /, dirent.name,
- NULL);
-
-if (modssl_X509_INFO_load_file(ptemp, sk, fullname)) {
-ok = TRUE;
-}
-}
-
-apr_dir_close(dir);
-
-return ok;
-}
-
/* _
**
** Custom (EC)DH parameter support
Index: modules/ssl/ssl_util_ssl.h
===
--- modules/ssl/ssl_util_ssl.h (revision 1677159)
+++ modules/ssl/ssl_util_ssl.h (working copy)
@@ -68,7 +68,6 @@ char *modssl_X509_NAME_to_string(apr_pool_t
BOOLmodssl_X509_getSAN(apr_pool_t *, X509 *, int, int,
apr_array_header_t **);
BOOLmodssl_X509_match_name(apr_pool_t *, X509 *, const char *, BOOL,
server_rec *);
BOOLmodssl_X509_INFO_load_file(apr_pool_t *, STACK_OF(X509_INFO) *,
const char *);
-BOOLSSL_X509_INFO_load_path(apr_pool_t *, STACK_OF(X509_INFO) *, const
char *);
int SSL_CTX_use_certificate_chain(SSL_CTX *, char *, int,
pem_password_cb *);
char *SSL_SESSION_id2sz(unsigned char *, int, char *, int);
Re: mod_ssl namespacing: app_data2
On Fri, May 01, 2015 at 09:39:14AM -0400, Eric Covener wrote: On Fri, May 1, 2015 at 9:33 AM, Stefan Sperling s...@apache.org wrote: This moves symbols related to '2nd application data' into the ssl_ namespace. File-level static symbols have no external linkage so don't need a namespace. Same patch as before, but moving into modssl_ function namespace, instead of ssl_ which is used for private functions within OpenSSL. Hi Stefan -- I think CTR should be fine on these refactorings. So modssl_ has been agreed on? :) I'll go ahead. Thanks.
Re: Looking ahead to 2.4.13 / 2.2.30
Yeah... I was gonna propose that once I had the weekend to take a more in-depth look at 2.4... But I am +1 for a release v. soon. Yeah, I'll RM 2.4 On Apr 30, 2015, at 5:52 PM, William A Rowe Jr wr...@rowe-clan.net wrote: On Thu, Apr 2, 2015 at 4:46 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Tue, 31 Mar 2015 10:49:47 -0400 Jim Jagielski j...@jagunet.com wrote: BTW: Would it make sense to consider a release of 2.4.13 in April to coincide w/ ApacheCon? We've historically produced a release at the beginning of the con. It worked really well when we would hackathon two days, then retire to do other con stuff for the balance of the event with a new release in the hopper looking for votes. I'd love to see us tag and roll releases based on our efforts throughout the entire gathering, sometime in that following week. I offer to TR an update of 2.2 as well to pick up any issues we resolve over the course of that week. It seems that we have 2 groups of good things to come out of ApacheCon, some immediate fixes for things like BSD project efforts, some pretty straightforward defects that have been resolved... and then there's a bunch of energy about enhancements and the h2 universe. In the short term, WDYT about giving the trees a week to settle, grab the low hanging fruit and move forward for 2.4.13 and 2.2.30 end of this coming week? Guessing Jim's up for RM'ing 2.4.13, and I'm happy to TR 2.2.30 in tandem. Concerns / observations / thoughts? Bill
Re: mod_ssl namespacing: app_data2
On Sat, Apr 18, 2015 at 07:22:06PM +0200, Stefan Sperling wrote:
This moves symbols related to '2nd application data' into the ssl_ namespace.
File-level static symbols have no external linkage so don't need a namespace.
Same patch as before, but moving into modssl_ function namespace,
instead of ssl_ which is used for private functions within OpenSSL.
Index: modules/ssl/README.dsov.fig
===
--- modules/ssl/README.dsov.fig (revision 1677132)
+++ modules/ssl/README.dsov.fig (working copy)
@@ -339,7 +339,7 @@ Single
4 0 0 200 0 20 8 0. 4 90 465 11745 4770 -method\001
4 0 0 200 0 20 8 0. 4 120 1665 9945 6480 X509_STORE_CTX_get_app_data()\001
4 0 0 200 0 20 8 0. 4 120 1215 10980 6705 SSL_CTX_get_cert_store()\001
-4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 SSL_get_app_data2()\001
+4 0 0 200 0 20 8 0. 4 120 1020 8280 5130 modssl_get_app_data2()\001
4 0 0 100 0 18 20 0. 4 270 1290 10710 7605 OpenSSL\001
4 0 0 100 0 18 12 0. 4 180 720 10710 7785 [Crypto]\001
4 0 0 100 0 18 20 0. 4 270 1290 10935 3645 OpenSSL\001
Index: modules/ssl/README.dsov.ps
===
--- modules/ssl/README.dsov.ps (revision 1677132)
+++ modules/ssl/README.dsov.ps (working copy)
@@ -1002,7 +1002,7 @@ gs 1 -1 sc (X509_STORE_CTX_get_app_data\(\)) col0
gs 1 -1 sc (SSL_CTX_get_cert_store\(\)) col0 sh gr
/Helvetica-Narrow-iso ff 120.00 scf sf
8280 5130 m
-gs 1 -1 sc (SSL_get_app_data2\(\)) col0 sh gr
+gs 1 -1 sc (modssl_get_app_data2\(\)) col0 sh gr
/Helvetica-Bold-iso ff 180.00 scf sf
3645 1620 m
gs 1 -1 sc (SSLDirConfig) col0 sh gr
Index: modules/ssl/mod_ssl.c
===
--- modules/ssl/mod_ssl.c (revision 1677132)
+++ modules/ssl/mod_ssl.c (working copy)
@@ -539,7 +539,7 @@ int ssl_init_ssl_connection(conn_rec *c, request_r
}
SSL_set_app_data(ssl, c);
-SSL_set_app_data2(ssl, NULL); /* will be request_rec */
+modssl_set_app_data2(ssl, NULL); /* will be request_rec */
sslconn-ssl = ssl;
Index: modules/ssl/ssl_engine_init.c
===
--- modules/ssl/ssl_engine_init.c (revision 1677132)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -348,7 +348,7 @@ apr_status_t ssl_init_Module(apr_pool_t *p, apr_po
*/
ssl_add_version_components(p, base_server);
-SSL_init_app_data2_idx(); /* for SSL_get_app_data2() at request time */
+modssl_init_app_data2_idx(); /* for modssl_get_app_data2() at request time
*/
init_dh_params();
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c (revision 1677132)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -229,7 +229,7 @@ int ssl_hook_ReadReq(request_rec *r)
}
}
#endif
-SSL_set_app_data2(ssl, r);
+modssl_set_app_data2(ssl, r);
/*
* Log information about incoming HTTPS requests
@@ -1385,7 +1385,7 @@ int ssl_callback_SSLVerify(int ok, X509_STORE_CTX
SSL *ssl = X509_STORE_CTX_get_ex_data(ctx,
SSL_get_ex_data_X509_STORE_CTX_idx());
conn_rec *conn = (conn_rec *)SSL_get_app_data(ssl);
-request_rec *r = (request_rec *)SSL_get_app_data2(ssl);
+request_rec *r = (request_rec *)modssl_get_app_data2(ssl);
server_rec *s = r ? r-server : mySrvFromConn(conn);
SSLSrvConfigRec *sc = mySrvConfig(s);
Index: modules/ssl/ssl_util_ssl.c
===
--- modules/ssl/ssl_util_ssl.c (revision 1677132)
+++ modules/ssl/ssl_util_ssl.c (working copy)
@@ -38,19 +38,19 @@
* also note that OpenSSL increments at static variable when
* SSL_get_ex_new_index() is called, so we _must_ do this at startup.
*/
-static int SSL_app_data2_idx = -1;
+static int app_data2_idx = -1;
-void SSL_init_app_data2_idx(void)
+void modssl_init_app_data2_idx(void)
{
int i;
-if (SSL_app_data2_idx -1) {
+if (app_data2_idx -1) {
return;
}
/* we _do_ need to call this twice */
-for (i=0; i=1; i++) {
-SSL_app_data2_idx =
+for (i = 0; i = 1; i++) {
+app_data2_idx =
SSL_get_ex_new_index(0,
Second Application Data for SSL,
NULL, NULL, NULL);
@@ -57,14 +57,14 @@
}
}
-void *SSL_get_app_data2(SSL *ssl)
+void *modssl_get_app_data2(SSL *ssl)
{
-return (void *)SSL_get_ex_data(ssl, SSL_app_data2_idx);
+return (void *)SSL_get_ex_data(ssl, app_data2_idx);
}
-void SSL_set_app_data2(SSL *ssl, void *arg)
+void modssl_set_app_data2(SSL *ssl, void *arg)
{
-SSL_set_ex_data(ssl, SSL_app_data2_idx, (char *)arg);
+SSL_set_ex_data(ssl, app_data2_idx, (char *)arg);
Re: mod_ssl namespacing: app_data2
On Fri, May 1, 2015 at 9:33 AM, Stefan Sperling s...@apache.org wrote: This moves symbols related to '2nd application data' into the ssl_ namespace. File-level static symbols have no external linkage so don't need a namespace. Same patch as before, but moving into modssl_ function namespace, instead of ssl_ which is used for private functions within OpenSSL. Hi Stefan -- I think CTR should be fine on these refactorings. -- Eric Covener cove...@gmail.com
