Bug report for Apache httpd-2 [2017/03/12]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 8713|Inf|Min|2002-05-01|No Errorlog on PROPFIND/Depth:Infinity| | 8867|Opn|Cri|2002-05-07|exports.c generation fails when using a symlink to| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |11294|New|Enh|2002-07-30|desired vhost_alias option| |11580|Opn|Enh|2002-08-09|generate Content-Location headers | |12033|Opn|Nor|2002-08-26|Graceful restart immediately result in [warn] long| |13599|Inf|Nor|2002-10-14|autoindex formating broken for multibyte sequences| |13661|Ass|Enh|2002-10-15|Apache cannot not handle dynamic IP reallocation | |14104|Opn|Enh|2002-10-30|not documented: must restart server to load new CR| |14496|New|Enh|2002-11-13|Cannot upgrade any version on Windows. Must uninst| |14922|Inf|Enh|2002-11-28| is currently hardcoded to 'apache2' | |15719|Inf|Nor|2002-12-30|WebDAV MOVE to destination URI which is content-ne| |16761|Inf|Nor|2003-02-04|CustomLog with pipe spawns process during config | |16811|Ass|Maj|2003-02-05|mod_autoindex always return webpages in UTF-8.| |17107|New|Min|2003-02-16|Windows should not install printenv | |17114|New|Enh|2003-02-17|Please add strip and install-strip targets to Make| |17244|Ass|Nor|2003-02-20|./configure --help gives false information regardi| |17497|Opn|Nor|2003-02-27|mod_mime_magic generates incorrect response header| |18325|New|Enh|2003-03-25|PAM support for suEXEC| |18334|Inf|Cri|2003-03-25|Server crashes when authenticating users against L| |19670|New|Enh|2003-05-05|content type header supplied upon PUT is thrown aw| |20036|Ass|Nor|2003-05-19|Trailing Dots stripped from PATH_INFO environment | |21260|New|Nor|2003-07-02|CacheMaxExpire directive not enforced ! | |21533|Ass|Cri|2003-07-11|Multiple levels of htacces files can cause mod_aut| |22484|Opn|Maj|2003-08-16|semaphore problem takes httpd down| |22686|Opn|Nor|2003-08-25|ab: apr_poll: The timeout specified has expired (7| |22898|Opn|Nor|2003-09-02|nph scripts with two HTTP header | |23167|Inf|Cri|2003-09-14|--enable-layout never goes to apr apr-util| |23181|New|Nor|2003-09-15|Status 304 (Not modified) and chunking leads to an| |23238|New|Cri|2003-09-18|non-async-signal-safe operations from signal handl| |23330|New|Enh|2003-09-22|Enhance ApacheMonitor to view and control Tomcat s| |23911|Opn|Cri|2003-10-18|CGI processes left defunct/zombie under 2.0.54| |24031|New|Enh|2003-10-23|Passphrase protected private key in SSLProxyMachin| |24095|Opn|Cri|2003-10-24|ERROR "Parent: child process exited with status 32| |24437|Opn|Nor|2003-11-05|mod_auth_ldap doubly-escapes backslash (\) charact| |24890|Opn|Nor|2003-11-21|Apache config parser should not be local aware ( g| |25014|New|Enh|2003-11-26|A flexible interface for mod_log_config | |25201|New|Enh|2003-12-04|Provide Cache Purge operation | |25240|Inf|Enh|2003-12-05|SSL Library Error: 336105671 logged as information| |25435|New|Enh|2003-12-11|sethandler and directoryindex not playing nice| |25469|Opn|Enh|2003-12-12|create AuthRoot for defining paths to auth files | |25484|Ass|Nor|2003-12-12|Non-service Apache cannot be stopped in WinXP | |25543|Inf|Nor|2003-12-15|mod_proxy_ajp overwrites existing response headers| |25667|New|Nor|2003-12-19|Memory leak in function ssl_scache_dbm_retrieve().| |25863|New|Enh|2004-01-02|new per-host initialization hooks | |26005|New|Nor|2004-01-08|SERVER_NAME incorrect when using IPv6 address in U| |26142|New|Maj|2004-01-14|EnableSendFile Off for Windows XP Home| |26153|Opn|Cri|2004-01-15|Apache cygwin directory traversal vulnerability | |26368|New|Min|2004-01-23|File extensions in AddDescription treated as part | |26446|New|Nor|2004-01-26|flush buckets followed by eos bucket emit multiple| |26478|New|Enh|2004-01-28|mod_dav does not expose a method for setting the D| |26835|New|Enh|
Re: svn commit: r1783256 - /httpd/httpd/branches/2.4.x/STATUS
On 2/20/2017 10:58 AM, William A Rowe Jr wrote: > On Sat, Feb 18, 2017 at 4:44 PM, Daniel Ruggeri wrote: >> Hi, Bill; >>I've replied about the pre_connnection situation - hoping someone can >> give the proposed patch a test as I don't have a handy H2 testbed. > Yup! Will review that thread - it's the -1 half (as opposed to a general -0 > half > for a 'pause' request while I was trying to get to reviewing the > original commit.) No worries at all. Reviews are important. I am curious what you mean about -1 half vs -0 half, though. Is that -1.5 vs -.5? :-) > >> On the other comment, can you help me understand what redundant code is >> happening per-request? When manipulating the request, there are only >> four things happening differently: >> 1. A check that we have data stored away from the connection filter >> 2. A check that the connection data has a client IP >> 3. The assignment of the data to the request_rec's structure and logging >> at TRACE1 >> 4. If no data was found, a check to see if it was optional and a logging >> statement/return according to that result > AIUI; the directives are all configured per-Server, the PROXY protocol data > is fixed for the lifespan of the Connection. The PROXY protocol is > significantly > more binding that either x-f-f or even x-remoteip. I'm not even sure where the > 'optional' scheme originated; if present when not allowed, that's a probable > abuse pattern, and when not present when honored, that too indicates some > malfunction and traffic shouldn't proceed IMO. I don't know that the optional > list should be shipped, it's far too simple to create a completely insecure > setup that won't raise eyebrows. The PROXY protocol reference spec states > the connection (by origin or destination IP) follows the PROXY protocol, or > it does not. Sorry to mix threads. I just replied a moment ago with a bit of reasoning behind the Optional use case. While it's possible that a server admin could mistakenly enable something they don't intend to or open things up more than they should, that's applicable any time someone enables some sort of authnz. I'm happy to reinforce this point in the docs for the Optional case but I still think enough utility is there to include it. > > Beyond that concern, I'm wondering if we shouldn't be using the *original* > design of mod_remoteip, changing the conn_rec client_addr/client_ip (and > null out remote_host/logname) and never alter it between requests. > > We can leave a conn pool note behind for the per-req processing, to retrieve > the proxy IP into a req variable if desired doing the rest of the > remoteip request > phase, but the remaining per-req code and processing is near insignificant. > > Thoughts? > >> This should all be quite straight forward per request... In fact, it's a >> much shorter logical path and less work than having to parse the >> X-Forwarded-For header. > So I was unspooling how we would handle stacked variables. > > Any PROXY protocol is the nearest hop; if multiple PROXY protocol header > lines occurred, the closest would be transmitted first, etc. I'm not sure if multiple PROXY lines are permitted. Looking at section 4.1, I think the intent is that PROXY-aware servers would continue propagating the original client IP address in any PROXY headers it emits. For example, in the diagram in section 4.1, PX2 should emit a PROXY header to the backend server that has the client IP it received from the PROXY header in PX1. Ref: http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt > All local x-remoteip style values would be the next most distant hop; very > similar to the haproxy protocol, it indicates some absolutely trusted edge > router/balancer. > > Any x-f-f that occurs would reflect all the next most distant hops. Finally, > any 'Forwarded' header (rfc7239) are the most distant hops. I'm basing > that conclusion on the fact that all 'Forwarded'-aware intermediaries which > construct a 'Forwarded' header would not carry the x-f-f, but concatenate > these as closer than the nearest 'Forwarded'-aware hop. So the presence > of an x-f-f header indicates the presence of a 'Forwarded'-unaware agent > between this incoming connection and the closest 'Forwarded'-aware agent. Yep, I follow the thought process and agree. This assumes that the intermediary isn't being clever or dumb by... * Sending the traffic as it received it (so not technically complying with any of the methods of propagating client and intermediary info) * Sending an appropriate 7239 header, but blindly passing X-Forwarded-For * Rewriting both headers to contain the same data in their expected formats FWIW, I feel the struggle of unwrapping all of this, too. At $dayjob, because of the potential silliness of various intermediaries, we chose to create a custom header that is always written (dropped if it comes to us) when our edge devices receive a connection. > > I'm not suggesting these two enhancements, PROXY and RFC7239 are > intert
Re: mod_remoteip and mod_http2 combined
Thanks, all, for the patience as I finally got back to this.
On 2/24/2017 11:05 AM, Sander Hoentjen wrote:
>
> On 02/20/2017 07:48 PM, William A Rowe Jr wrote:
>> On Sat, Feb 18, 2017 at 4:25 PM, Daniel Ruggeri wrote:
>>> On 2017-02-15 09:07 (-0600), William A Rowe Jr wrote:
On Wed, Feb 15, 2017 at 9:02 AM, Sander Hoentjen
wrote:
> mod_remote ip has:
> /* mod_proxy creates outgoing connections - we don't want those */
> if (!remoteip_is_server_port(c->local_addr->port)) {
> return DECLINED;
> }
> I am guessing something similar is needed for h2 connections?
I suspect that the mod_remoteip logic is wrong, that it should be guarding
against any subordinate connections and examining only explicitly
configured
ports / origin IPs. the PROXY protocol is not part of the HTTP protocol and
incompatible with it, so the trust list logic isn't directly compatible
(this is
clearly explained in the PROXY pseudo-RFC.)
>>> Hi, Bill. That is what the module is doing. The original authors wrote it
>>> to have a list of virtual hosts it is explicitly enabled for and explicitly
>>> disabled for. I added a third list for optional vhosts. In the
>>> pre_connection hook, it checks to see if the connection's local_addr (which
>>> should normally be the server's IP) is explicitly configured to enable
>>> PROXY handling. It then checks to see if the local port is a server port.
>>>
>>> Looking at the logs shared, 192.168.122.249:84 is the server IP:Port combo
>>> and is also the local IP:Port from mod_h2. If h2 sets the master of this
>>> connection, then we could skip the whole ordeal with this patch:
>>>
>>> Index: modules/metadata/mod_remoteip.c
>>> ===
>>> --- modules/metadata/mod_remoteip.c (revision 1781701)
>>> +++ modules/metadata/mod_remoteip.c (working copy)
>>> @@ -862,6 +862,10 @@
>>> remoteip_conn_config_t *conn_conf;
>>> int optional;
>>>
>>> +if (c->master != NULL) {
>>> +return DECLINED;
>>> +}
>>> +
>>> conf = ap_get_module_config(ap_server_conf->module_config,
>>> &remoteip_module);
>>>
>>> .. but I don't know if that potentially means we are looking at the wrong
>>> connection.
> First I'll say that with the "Optional" mode it worked, just not with On
> I just tried this patch and as far as I have tested this seems to work
> fine in On mode, as well as in Optional. I do see some other issue, but
> that is probably in my own code, I'll try to track that down later.
This is good news and about what I was expecting to happen. I will add
this to the commit I've got coming that incorporates a lot of Ruediger's
feedback.
>> That should be close, but need to ensure c->master is initialized for
>> http as well
>> where there is no master/subordinate.
> I am not sure what this means, how should I test this?
Hi, Bill - also hoping for a bit more input. Since PROXY protocol is not
tied to any particular layer 7 protocol, I don't think we'd have to
verify it is initialized for HTTP - just that there is no master at all.
At least, that's my understanding so I appreciate any corrections.
>> If the 'optional' (unwise) feature were removed, the decision to
>> inject the filter before
>> the http or h2 filter would be trivial, it would step out of the way
>> after the first-pass
>> (and perhaps not need to live on the filter stack at all - if we do a
>> fixed read against
>> the core filter - we hopefully know the number of bytes affected early
>> and can then
>> do a second read to complete the v1 vs v2 read?) --- all before we are
>> in a multiple
>> pipeline state.
I don't think that is the case because the module was also written to
support PROXY header consumption in a name-based virtual host context,
too, where ServerName abc may require it but ServerName xyz does not.
Agreed, if it were simply all or nothing (either it's enabled on this
connection or not), we could avoid some of these gymnastics but I think
that use case as well as the Optional use case requires it.
>> If we move to a conn_rec oriented one-shot nothing happens during the request
>> phase at all.
>>
>> By looking at the protocol filter stack, we should be able to glean
>> whether we are
>> talking to the core filter, or an 'unexpected' non-network filter, right?
>>
> I myself have no use-case at the moment for the "Optional" mode, maybe
> others do.
Sure, to clarify, the Optional use case came from a member on one of our
cousin projects (Tomcat) Chris Schultz as well as my own use cases. It
is useful for internally accessing the site from behind the
loadbalancer. When there is a publicly addressed upstream loadbalancer
(Amazon ELB or just HAProxy itself) talking to RFC1918 addressed or
non-routeable backend httpd servers, it becomes impossible to enable
internal communication on the RFC1918 space to the back
