Hello Eugene,
Thanks for pointing out your bug report 54651.
It answers a mystery I had with regard to bug report 55635.
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55635
As you can see in comment 1, I submitted results that were somewhat
different from those of the bug reporter.
In comment 3, I gave an explanation of the bug reporter's results.
But that did not explain my own results.
Once I applied your patch from bug 54651, my results matched those of
the bug reporter in 55635.
It appears that the bug reporter in 55635 had the patch for 54651 applied.
So I confirm that your patch is indeed valid and useful.
Since I am a relatively new developer (1 year) for the Apache httpd
project, I do not have committer access.
Perhaps there is a committer who is interested in mod_remoteip that will
consider committing the 54651 patch to trunk.
I will update bug 54651 to help bring it some attention.
Thanks again,
Mike Rumph
On 12/15/2013 1:00 AM, Lam, Eugene wrote:
Secondly, with each cycle of the while loop the apparent client IP is
compared against the proxymatch_ip list.
Are you referring to the while loop here:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/metadata/mod_remotei
p.c?view=markup&pathrev=1550828#l247
Not to detract from the original topic, but while we're here, an equally
serious bug does exists on line 256 ... with a simple fix.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54651
If anyone would kindly verify and integrate the provided patch, this 1
year old bug can be put to bed.
EugeneL
On 12/13/13 4:26 PM, "Mike Rumph" <mike.ru...@oracle.com> wrote:
On 12/11/2013 2:18 PM, William A. Rowe Jr. wrote:
On Mon, 09 Dec 2013 11:10:46 -0800
Mike Rumph <mike.ru...@oracle.com> wrote:
As you can see from the bug report, I have been looking into this.
It might also be important to consider the related bug 55637:
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55637
Closed invalid. The incorrect assumptions are very similar to but
distinct from the 55635 case.
In this case, let's use a car's title as it's internal proxy document
and the car's ignition keys as the trusted proxy document. Although
you might trust one with your car keys, they can go ahead and share
those keys with yet another party. We would not want to design the
remoteip logic to then let that individual hand another party the title
to the vehicle :) Once the InternalProxy list is exhausted and we have
begun processing the TrustedProxy list, we can never again assign the
next apparent proxy to be an InternalProxy. That would be a claim by
an external party whom we can't assign that much trust to.
So I think you are referring to the difference between
RemoteIPInternalProxy and RemoteIPTrustedProxy, correct?
Your explanation sounds reasonable, but to me it doesn't appear to
exactly match the actual implementation in mod_remoteip.c.
First of all, both directives are combined into one single list (not two).
In remoteip_modify_request() this is referred to as config->proxymatch_ip.
The elements within this list are distinguished by the "internal" field.
RemoteIPInternalProxy elements are marked as internal, while
RemoteIPTrustedProxy elements are not.
The only difference in processing of the "internal" field is in the
handling of local/private subnets.
So as I read the code, it is not a difference in level of trust, but
rather a matter of name space.
This makes sense to me.
For example, IP address 10.1.2.3 only has meaning within a specific
local network.
So if an external proxy is referring to 10.1.2.3, it would probably not
be intending a server in the local network that just happens to have
10.1.2.3 has its IP address.
Secondly, with each cycle of the while loop the apparent client IP is
compared against the proxymatch_ip list.
It may be internal or not.
There is nothing I see in the code that prevents a cycle with internal
proxy from following a cycle with external proxy.
So if your explanation is the way the code is intended, there may exist
some subtle error cases.
Experiments to investigate this could take us outside the scope of the
original bug reports, so I decided to discuss it here instead.
The setups so far have not included a RemoteIPProxiesHeader.
But if it is included, the mod_remote documentation seems to indicate
that the value should be different from the RemoteIPHeader.
-
http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxies
header
RemoteIPHeader X-Forwarded-For
RemoteIPProxiesHeader X-Forwarded-By
You are correct.
From my analysis so far it appears that mod_remoteip is behaving as
documented. But the documentation is a little difficult to understand.
Correct, and I'm not sure how it can be improved. Feel free to quote,
rephrase or build upon my responses to the bug tickets.
