Fwd: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua: lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
Original Message
Subject:svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua:
lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
Date: Sun, 05 Aug 2012 19:57:45 GMT
From: humbed...@apache.org
Author: humbedooh
Date: Sun Aug 5 19:57:44 2012
New Revision: 1369656
URL: http://svn.apache.org/viewvc?rev=1369656view=rev
Log:
Add a server scope for Lua states (in LuaScope), which creates a pool of
states with manageable
minimum and maximum size.
Modified:
httpd/httpd/trunk/modules/lua/lua_vmprep.c
httpd/httpd/trunk/modules/lua/lua_vmprep.h
httpd/httpd/trunk/modules/lua/mod_lua.c
httpd/httpd/trunk/modules/lua/mod_lua.h
Modified: httpd/httpd/trunk/modules/lua/lua_vmprep.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_vmprep.c?rev=1369656r1=1369655r2=1369656view=diff
==
--- httpd/httpd/trunk/modules/lua/lua_vmprep.c (original)
+++ httpd/httpd/trunk/modules/lua/lua_vmprep.c Sun Aug 5 19:57:44 2012
@@ -23,6 +23,15 @@
APLOG_USE_MODULE(lua);
+#if APR_HAS_THREADS
+apr_thread_mutex_t *ap_lua_mutex;
+
+void ap_lua_init_mutex(apr_pool_t *pool, server_rec *s)
+{
+apr_thread_mutex_create(ap_lua_mutex, APR_THREAD_MUTEX_DEFAULT, pool);
+}
+#endif
+
Shouldn't you use the httpd mutex API here to keep the mutex type configureable
in a generic way?
See util_mutex.c / ap_mutex_register.
Regards
Rüdiger
Re: Fwd: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua: lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
On 08/06/2012 09:23 AM, Rüdiger Plüm wrote:
Original Message
Subject: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua:
lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
Date: Sun, 05 Aug 2012 19:57:45 GMT
From: humbed...@apache.org
Author: humbedooh
Date: Sun Aug 5 19:57:44 2012
New Revision: 1369656
URL: http://svn.apache.org/viewvc?rev=1369656view=rev
Log:
Add a server scope for Lua states (in LuaScope), which creates a pool
of states with manageable
minimum and maximum size.
Modified:
httpd/httpd/trunk/modules/lua/lua_vmprep.c
httpd/httpd/trunk/modules/lua/lua_vmprep.h
httpd/httpd/trunk/modules/lua/mod_lua.c
httpd/httpd/trunk/modules/lua/mod_lua.h
Modified: httpd/httpd/trunk/modules/lua/lua_vmprep.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/lua/lua_vmprep.c?rev=1369656r1=1369655r2=1369656view=diff
==
--- httpd/httpd/trunk/modules/lua/lua_vmprep.c (original)
+++ httpd/httpd/trunk/modules/lua/lua_vmprep.c Sun Aug 5 19:57:44 2012
@@ -23,6 +23,15 @@
APLOG_USE_MODULE(lua);
+#if APR_HAS_THREADS
+apr_thread_mutex_t *ap_lua_mutex;
+
+void ap_lua_init_mutex(apr_pool_t *pool, server_rec *s)
+{
+apr_thread_mutex_create(ap_lua_mutex, APR_THREAD_MUTEX_DEFAULT,
pool);
+}
+#endif
+
Shouldn't you use the httpd mutex API here to keep the mutex type
configureable in a generic way?
See util_mutex.c / ap_mutex_register.
Regards
Rüdiger
Hi Rüdiger,
When I looked into how httpd works with mutexes, I looked at mod_dbd for
inspiration, and it used the apr_thread_mutex stuff for its handling of
the process pools, so that's what I used. Shame on me :)
I have changed it to use the ap_mutex functions/structs now, so all
should be well (unless I managed to mess that up too ;) ).
With regards and thanks as usual for your reviews,
Daniel.
Re: Fwd: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua: lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
On 08/06/2012 11:46 AM, Plüm, Rüdiger, Vodafone Group wrote:
-Original Message-
From: Daniel Gruno [mailto:rum...@cord.dk]
Sent: Montag, 6. August 2012 11:31
To: dev@httpd.apache.org
Subject: Re: Fwd: svn commit: r1369656 - in
/httpd/httpd/trunk/modules/lua: lua_vmprep.c lua_vmprep.h mod_lua.c
mod_lua.h
On 08/06/2012 09:23 AM, Rüdiger Plüm wrote:
Original Message
Subject: svn commit: r1369656 - in /httpd/httpd/trunk/modules/lua:
lua_vmprep.c lua_vmprep.h mod_lua.c mod_lua.h
Date: Sun, 05 Aug 2012 19:57:45 GMT
From: humbed...@apache.org
--- httpd/httpd/trunk/modules/lua/lua_vmprep.c (original)
+++ httpd/httpd/trunk/modules/lua/lua_vmprep.c Sun Aug 5 19:57:44
2012
@@ -23,6 +23,15 @@
APLOG_USE_MODULE(lua);
+#if APR_HAS_THREADS
+apr_thread_mutex_t *ap_lua_mutex;
+
+void ap_lua_init_mutex(apr_pool_t *pool, server_rec *s)
+{
+apr_thread_mutex_create(ap_lua_mutex, APR_THREAD_MUTEX_DEFAULT,
pool);
+}
+#endif
+
Shouldn't you use the httpd mutex API here to keep the mutex type
configureable in a generic way?
See util_mutex.c / ap_mutex_register.
Regards
Rüdiger
Hi Rüdiger,
When I looked into how httpd works with mutexes, I looked at mod_dbd for
inspiration, and it used the apr_thread_mutex stuff for its handling of
the process pools, so that's what I used. Shame on me :)
I have changed it to use the ap_mutex functions/structs now, so all
should be well (unless I managed to mess that up too ;) ).
With regards and thanks as usual for your reviews,
Sorry for pointing you in the wrong direction. The httpd mutex API is only for
proc mutexes not for thread mutexes like you used initially (I assume you
only wanted to
coordinate multiple threads within one process and not multiple child
processes).
I did not notice this initially. So you can just revert your last commit.
Sorry for the inconvenience.
Regards
Rüdiger
Oh well, gives me something to do today ;)
With regards,
Daniel.
Re: svn commit: r1364330 - /httpd/httpd/branches/2.4.x/STATUS
On 07/22/2012 05:32 PM, rj...@apache.org wrote: Author: rjung Date: Sun Jul 22 15:32:22 2012 New Revision: 1364330 URL: http://svn.apache.org/viewvc?rev=1364330view=rev Log: Propose. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1364330r1=1364329r2=1364330view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Sun Jul 22 15:32:22 2012 @@ -296,6 +296,13 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: +1: rjung rjung: sf: you applied it to trunk, care to vote? + * mod_ssl: Work correctly with a development version of OpenSSL. + trunk patch: http://svn.apache.org/viewvc?view=revisionrevision=1358167 and + http://svn.apache.org/viewvc?view=revisionrevision=1358166 + 2.4.x patch: http://people.apache.org/~rjung/patches/ssl-support-uninstalled-openssl-2_4.patch + +1: rjung + rjung: ben: you applied it to trunk, care to vote? + A list of further possible backports can be found at: http://people.apache.org/~rjung/patches/possible-backports-httpd-trunk-2_4.txt If you want to propose one of those, please add them here. I can't seem to find http://people.apache.org/~rjung/patches/ssl-support-uninstalled-openssl-2_4.patch - did you forget to upload it? :) With regards, Daniel.
Re: Additional core functions for mod_lua
On 08/06/2012 12:17 AM, Stefan Fritsch wrote: Nice work. If you talk about the existing apache2 library, you mean it is existing in mod_lua? Or is it an external file? I meant the apache2 table we already have in place for return codes. Either that or we create a new table/library to hold them. There is some overlap with the r table: These already exist: apache2.context_document_root apache2.context_prefix apache2.add_output_filter Scrapped These can be done wit r.subprocess_env: apache2.getenv apache2.setenv Also scrapped Wouldn't it make sense to add those new functions which are really related to the request (as opposed to just using the request pool) to the r table, too? Yes, I had planned to add some of the functions that only apply to requests to the existing r structure, so we could do things like r:flush() and use r.port etc. If there's (lazy) consensus, I can just add all the functions pertaining to the request to that structure. Some other random notes: apache2.requestbody: This should take a size limit as argument. Done apache2.get_server_name: The example and the synopsis don't agree if this should have an argument Fixed apache2.get_server_name_for_url: This is missing but would be very useful. Added With regards, Daniel.
Re: Additional core functions for mod_lua
If no one objects, I'll start moving in some functions to the mod_lua core, starting with the ones that pertain to obtaining a static value from the request/server, as well as the flush and sendfile function, and making them part of the request_rec package. This includes the following (as they will appear when imported): r:flush() - Flushes the output buffer r:sendfile(filename) - Sends a file using sendfile if available r.port -the port in use by the request r.banner - the server banner r.options - the Options directive for the request r.allowoverrides - the AllowOverride directive for the request r.started - the time the server was (re)started r.basic_auth_pw - the basic auth password, if any was sent r.limit_req_body - The current request body limit (or 0 for none) r.server_built -The time the server was built r.is_initial_req - Whether this is the initial request or a subreq r.remaining - The remaining bytes in the request body r.some_auth_required - Whether some authorization is/was required r.server_name - The server name for the request r.auth_name - The realm used (if any) for authorization This leaves the following functions still in the apache2 package - If you'd rather see any of them moved to the request_rec package, do say so - : apache2.base64_encode - Encode a string in base64 apache2.base64_decode - Decode a base64 string apache2.md5 - Generate an MD5 hash apache2.sha1 - Generate a SHA-1 hash apache2.escape -URL-escape a string apache2.unescape - unescape an URL-encoded string apache2.mpm_query - Query the MPM for information apache2.expr - Evaluate an ap_expr string apache2.scoreboard_process -Query the process scoreboard apache2.scoreboard_worker - Query a worker scoreboard apache2.clock - Returns the current time in microseconds apache2.requestbody - Fetches (or saves) the request body apache2.dbopen -Opens up a database connection (supports both apr_dbd and mod_dbd) apache2.add_input_filter - Adds an input filter to the request apache2.module_info - Queries the server for info about a mod apache2.loaded_modules -Lists all the loaded modules apache2.runtime_dir_relative - Returns a path relative to runtime dir apache2.server_info - Returns information about the executable apache2.set_document_root - Sets the document root for a request apache2.add_version_component - Adds a version component apache2.os_escape_path -Escapes a path as a URL apache2.strcmp_match - Does a strcmp_match (the foo* kind) apache2.set_keepalive - Set the keepalive status for a request apache2.make_etag - Creates an entity tag apache2.send_interim_response - Sends an interim response (or does it?) apache2.custom_response - Sets a custom response for an error msg apache2.exists_config_define - Query whether a define was made apache2.state_query - Queries the server for state info apache2.stat - Stats a file and returns info as a table apache2.regex - Evaluates regular expressions apache2.sleep - Sleeps for N seconds (accepts floats) apache2.get_server_name_for_url Servername for URL purposes Full descriptions and examples are still available at http://people.apache.org/~humbedooh/lua_ap/ if you need more info. If anyone has any other requests for internal functions they'd like to use in mod_lua, just speak up, I'm always happy to include more functionality. With regards, Daniel.
Re: RequireAll: seems to evaluate require lines unnecessarily
On 06 Aug 2012, at 12:01 AM, Stefan Fritsch wrote: The API is currently such that an authz provider must return AUTHZ_DENIED_NO_USER instead of AUTHZ_DENIED if its result may change after authentication. Require expr in 2.4.2 does not do that. But it will be fixed in 2.4.3 with http://svn.apache.org/viewvc?view=revisionrevision=1364266 I'm away for part of this week, I'll try this out when I get back. My concern at the API is that it seems that some of the Require lines are AUTHN related, while others are AUTHZ. In theory, if a single Require check fails AUTHN, it nullifies AUTHZ - you cannot know if the AUTHZ would have succeeded or failed until AUTHN has occurred successfully. This in turn means that if a line like Require valid-user fails, you can draw no conclusion about any of the AUTHZ lines, they might have succeeded, they might have failed, impossible to know with the information at hand. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: utf-8 - punycode for ServerName|Alias?
On 8/1/2012 5:01 PM, Reindl Harald wrote: there is simply no need for UTF8 in servrnames the nslookup you see is only a user-view there are only ASCII chars in dns and http-config without any special char and that is why IDN exists ServerAlias xn--wrmlach-n2a.at www.xn--wrmlach-n2a.at you will find no other expression than xn--wrmlach-n2a.at for würmlach.at in dns, httpd and other services while nslookup and any browser are happy with the special chars Ok, now I'm entirely following you, thanks :) Based on your feedback, I have a couple of observations; 1. The ServerAlias above will continue to work, never intended otherwise. Some of us like to work closer to the wire than others. 2. IDN -does- exist, and list/forum traffic suggests there are users who want IDN to be recognized in a native representation. I propose we support only utf-8 in .conf files for that native representation and will prepare a patch that offers that support -for those who desire it-. 3. Some users, like yourself, will want to always see IDN mapped values in the access/error log. Others will want to always see utf-8, and I'll prepare a patch that allows either behavior. I don't plan to spend a lot of time on simultaneous use of both behaviors, but if it turns out to be trivial, there may be a finer grained support. 4. As you say, browser and nslookup users already benefit from this silent translation. httpd users are users, of varying skill and comprehension. There's no need to be exclusionary, IMHO.
Re: mpm-itk and upstream Apache, once again
On 8/5/2012 8:32 AM, Steinar H. Gunderson wrote: On Sun, Aug 05, 2012 at 11:05:59AM -0400, Jeff Trawick wrote: Great! I'll do something about the remaining patch before long. When the time comes, do we have any hopes of getting this back from trunk to 2.4, or would it need to wait for 2.6/3.0? FWIW, the mpm-itk security hardening that was discussed (running with uid != 0, and limiting setuid/setgid ranges through seccomp) is starting to come quite nicely along, although the problem of initgroups() remains (a rogue process with CAP_SETGID can add any supplementary group it pleases, and seccomp is unable to check it), and there's been very limited user testing so far. I guess we can't get fully down to the level of prefork, but it can get pretty close. Steinar, I solved a very similar problem by spinning off a low-numbered port daemon which accesses resources (in this case, port 21 or similar) and returns the fd to the caller after it evaluates whether that request is permitted by the configuration parsed when it was launched. The solution might give you some ideas on how this mpm could have very limited root privileges with very specific purposes, and not at risk from any remote code execution flaws discovered in the future; http://svn.apache.org/repos/asf/httpd/mod_ftp/trunk/modules/ftp/ftp_lowportd.c Hope it inspires some interesting improvements :) Bill
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 8/5/2012 10:10 PM, Kaspar Brand wrote: On 05.08.2012 14:38, Guenter Knauf wrote: Am 05.08.2012 10:10, schrieb Kaspar Brand: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) what about splitting into two arguments: --with-ssl-include= --with-ssl-lib= this would be equal to what many other configure also use ... That's an option, yes, although the way the proposed option would work doesn't mirror the typical case of --with-xyz-include/--with-xyz-lib (i.e., add those args with -I and -L): --with-ssl-builddir forces mod_ssl to always be linked with the static libraries in that directory. Maybe --with-ssl-static-libdir would be a more appropriate name? Why not simply consume the installed openssl.pc?
Re: svn commit: r1364330 - /httpd/httpd/branches/2.4.x/STATUS
On 06.08.2012 12:32, Daniel Gruno wrote: I can't seem to find http://people.apache.org/~rjung/patches/ssl-support-uninstalled-openssl-2_4.patch - did you forget to upload it? :) Yes :( Now there. By the way: I updated http://people.apache.org/~rjung/patches/possible-backports-httpd-trunk-2_4.txt yesterday, so it is pretty current. Regards, Rainer
Re: Linking mod_ssl with a specific OpenSSL version (Re: svn commit: r1358167 - in /httpd/httpd/trunk: acinclude.m4 modules/ssl/ssl_engine_init.c)
On 05.08.2012 10:10, Kaspar Brand wrote: On 08.07.2012 10:30, Kaspar Brand wrote: On 06.07.2012 14:41, b...@apache.org wrote: Author: ben Date: Fri Jul 6 12:41:10 2012 New Revision: 1358167 URL: http://svn.apache.org/viewvc?rev=1358167view=rev Log: Work correctly with a development version of OpenSSL. I suspect something similar is needed when there are two OpenSSL installations, one in a default location. I had another look at this, since it has been proposed for backporting to 2.4 in the meantime, and still think the following is true: If I'm understanding correctly, then this patch tries to support building against an OpenSSL source tree (or perhaps a build directory where only make libs has been executed)? That is my understanding as well. (should have read make build_libs instead) It's a useful enhancement if mod_ssl can be linked with a specific OpenSSL version in a non-default location, but the current approach has at least one problem, AFAICT: it will only work if the directory pointed to by --with-ssl does not include shared libraries for OpenSSL (by default, OpenSSL only builds libssl.a and libcrypto.a, so the issue might not be obvious at first sight). Why wouldn't it work with shared libs? Because they usually have dependencies themselves that are ignored? I would suggest to use a separate configure argument to support this build option, e.g. --with-ssl-srcdir. We could, but I think if it would be easy to just add the logic to with-ssl to also work with a src directory it would be easier to use. I have no strong opinion on this though. I gave it a try, see the attached work-in-progress patch. While we're at it, I think we should also fix a flaw in the handling of the --with-ssl argument: in http://svn.apache.org/viewvc?view=revisionrevision=730926, acinclude.m4 was modified to always give pkg-config precedence over any argument specified through --with-ssl. While the rationale for this change becomes clear from the commit log, I consider it an unfortunate side effect that pkg-config always trumps any --with-ssl directory argument. My suggestion would be to handle OpenSSL paths in configure arguments like this, instead: 1) use --with-ssl-builddir for linking with the static OpenSSL libraries in that directory (and ignore --with-ssl in this case) 2) use --with-ssl for linking against an installed version of OpenSSL 3) use pkg-config to locate OpenSSL Does that sound like a reasonable proposal? Comments welcome, and test feedback would be much appreciated (remember to run buildconf after applying the patch to acinclude.m4, and before calling configure). I do like the idea to give with-ssl priority over pkgconfig. If a user chooses the ssl directory explicitly that should not be overwritten by pkgconfig. Of course one can still use pkgconfig info in the chosen directory to find dependency libs etc. Whether 1) and 2) needs to be a separate priority or simply using the same switch and auto-detect whether it is an installation directory or only a build directory is undecided to me. Regards, Rainer
