[prev in list] [next in list] [prev in thread] [next in thread] 

List:       privoxy-developers
Subject:    [privoxy-devel] [ ijbswa-Bugs-3349356 ] AI_ADDRCONFIG breaks
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2011-07-04 18:40:14
Message-ID: E1Qdo4B-0002TG-5I () sfs-ml-2 ! v29 ! ch3 ! sourceforge ! com
[Download RAW message or body]


Bugs item #3349356, was opened at 2011-07-02 14:24
Message generated for change (Settings changed) made by fabiankeil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=3349356&group_id=11118

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: version 3.0.17
> Status: Closed
> Resolution: Fixed
Priority: 5
Private: No
Submitted By: Raphael Marichez (falcog)
Assigned to: Fabian Keil (fabiankeil)
Summary: AI_ADDRCONFIG breaks connecting/binding to localhost

Initial Comment:
WIth no internet adresse other than the localhost address, AI_ADDRCONFIG prevents \
bind_port() and connect_to() to succeed. As a consequence, privoxy fails to start at \
boot time when the IP interfaces are long to be configured (e.g. wireless + dhcp).

This inconvienence can be seen in some linux distros bugzillas, e.g. \
https://bugzilla.redhat.com/show_bug.cgi?id=711587 I propose this patch.
I'm using gentoo linux.


----------------------------------------------------------------------

Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-04 18:38

Message:
Thanks for the insight, Petr.

I removed the AI_ADDRCONFIG hint in bind_port() and agree with Raphael and
you  that it should be kept in rfc2553_connect_to(). (Or at least it
shouldn't be removed without at the same time changing the rest of the code
to deal with the result.)

My interpretation of the quoted excerpt from the GNU libc manual is that
it only claims that glibc defaults to AI_V4MAPPED|AI_ADDRCONFIG if hints is
actually NULL (not merely because hints.ai_flags is 0), so Privoxy should
be fine.
But then again, we are talking about a GNU manpage here, and in my
experience they are often only an approximation of the actual behavior of
the code they "document" anyway.

I also added the following TODO list items:

---
93) Add a config directive to let Privoxy explicitly request either IPv4
(or IPv6) addresses, even if the system supports both. Could be useful as a
workaround for misconfigured setups where the libc returns IPv6 addresses
even if there's no IPv6 connectivity.

94) Add a config directive to let Privoxy prefer either IPv4 (or IPv6)
addresses, instead of trusting the libc to return them in an order that
makes sense. Like #93, this could be useful as a workaround for
misconfigured setups.
---

If the directive described in #93 is enabled (assuming it gets
implemented), Privoxy wouldn't need the AI_ADDRCONFIG in
rfc2553_connect_to(), and I think this could be good enough for most of the
few remaining use cases where it theoretical can cause problems.

----------------------------------------------------------------------

Comment By: Raphael Marichez (falcog)
Date: 2011-07-03 22:36

Message:
> Regarding listening socket on server site: I cannot find the bind_to()
> function in CVS sources. I guess you talk about bind_port().

of course :)

> If RFC 3493 states loop-back addresses
> do not count, just get rid of the flag before bind(). It's
> contra-productive there.

It's my opinion too.

> In general I'm not against removing the option from server part. However
I
> think it's useful and without any dark effects on client part and it
should
> be kept there.

I agree.

> Frankly, I don't like the attached patch. Any private fiddling with
> addresses is bad as instrumenting applications that behave each
differently
> and not respecting global configuration is night mare.

Again, i don't like it very much neither. It is a workaround more than a
bug, and was copy/pasted from other projects. And it doesn't address the
case where "something.example.com" resolves to 127.0.0.1. If you agree with
removing the flag from the bind_port() function, that solves the bug so I
agree too. The presence of the flag in the client function is probably not
annoying.

Cheers


----------------------------------------------------------------------

Comment By: Petr Písař (petrp)
Date: 2011-07-03 20:58

Message:
Well, purpose of AI_ADDRCONFIG is to omit useless addresses because of
missing corresponding local address.

This is especially useful when connecting to server. If you drop the
option from client socket, privoxy will iterate and attempt to connect(2)
to addresses that cannot be connected. This can slow things a little. E.g.
if you have IPv4 only hosts, connection to www.cesnet.cz:80 will result in
two connect(2) syscalls instead of one. Also the error message in fault web
page will refer to IPv6 address which could frustrate users a bit (because
the web page shows error from last attempt only). The bright site is
properly configured systems (/etc/gai.conf) sort getaddrinfo() response
list in order of available protocols, so the missing-proper-local-address
failures become after trying the possibly working ones. The dark site is
improperly configured systems could trick privoxy to try the bad addresses
first exhibiting some delay.

Regarding listening socket on server site: I cannot find the bind_to()
function in CVS sources. I guess you talk about bind_port(). The
AI_ADDRCONFIG flag is not so useful here. I think I put it there in case
privoxy would allow to put domain name into listen configuration statement.
If user must put numeric address he knows which protocol is it probably.
Maybe there could be problem if new protocol emerged that had address
syntactically indistinguishable from other one, then together with current
flaw not trying to bind to other resolved addresses, this could lead to
binding to inappropriate protocol. If RFC 3493 states loop-back addresses
do not count, just get rid of the flag before bind(). It's
contra-productive there.

In general I'm not against removing the option from server part. However I
think it's useful and without any dark effects on client part and it should
be kept there.

Just a remark about glibc: Manual states:

       According  to  POSIX.1-2001,  specifying  hints  as  NULL  should
cause
       ai_flags to be assumed as 0.  The GNU C library instead assumes a
value
       of  (AI_V4MAPPED | AI_ADDRCONFIG)  for  this  case, since this
value is
       considered an improvement on the specification.

So, provided this is still true, removal from privoxy will not cause any
change :(

Frankly, I don't like the attached patch. Any private fiddling with
addresses is bad as instrumenting applications that behave each differently
and not respecting global configuration is night mare.

----------------------------------------------------------------------

Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-02 21:56

Message:
Some of the potential problems of not using AI_ADDRCONFIG
rfc2553_connect_to() seem to be described in
https://bugzilla.redhat.com/show_bug.cgi?id=459756
and
https://bugzilla.mozilla.org/show_bug.cgi?id=467497
but it looks like we could work around them if we decided to drop it.

After grepping around in various sources (curl, Tor, Polipo ...), I get
the impression that it's common practice to not set AI_ADDRCONFIG and to
either only request a certain IP version, or to carefully look at the
returned addresses and trying to figure out which ones are usable.

Keeping rfc2553_connect_to() as is and only removing AI_ADDRCONFIG for
bind_to() for now seems like an option to me, too.

Of course I may be missing something, so I'll try to get an opinion from
Petr Písař (who made IPv6 support in Privoxy possible) first.

----------------------------------------------------------------------

Comment By: Raphael Marichez (falcog)
Date: 2011-07-02 17:52

Message:
Hi,

thanks for you reply.

I also agree that this patch is not fully satisfactory. That patch has
been proposed in https://bugzilla.mozilla.org/show_bug.cgi?id=614526 and in
http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/misc/prnetdb.c#2060

However, if you have in your /etc/hosts:
127.0.0.1       localhost skinfaxi

then with "host=skinfaxi" the problem will raise again.

I would personally prefer to avoid using AI_ADDRCONFIG at all. In
bind_port(), i don't see why there is AI_ADDRCONFIG. I'm sure it can be
dropped without any consequence. In connect_to(), it may be useful in some
circumstances.

I didn't want to simply drop AI_ADDRCONFIG, because i suppose that if
someone has put this flag in the code, he certainly has a reason for that.
I haven't found a changelog in Privoxy for that so I don't know. But
personally i see no problem in deleting this flag, at least in bind_port()



----------------------------------------------------------------------

Comment By: Fabian Keil (fabiankeil)
Date: 2011-07-02 15:40

Message:
Thanks a lot for the report and taking the time to write a patch.

I agree that this is a bug, but I'm not sure how it should be fixed yet.
Trying to white-list addresses that could resolve to a localhost address
seems a bit too fragile to me, though.

While the patch covers the GNU/Linuxism localhost.localdomain it doesn't
cover things like localhost.my.domain, localhost.local, loopback and other
aliases other platforms Privoxy runs on use.

I haven't tested it, but I think in case of bind_port() we could simply
drop the AI_ADDRCONFIG, as bind_port() is supposed to bind to the first
resolved address that works, trying multiple ones if necessary until no
address is left.

If it turns out that this currently doesn't work, it should be fixed.

In case of rfc2553_connect_to(), I suspect we can drop the AI_ADDRCONFIG,
too, but haven't properly looked into it yet. We obviously wouldn't want
Privoxy to try connecting to an external IPv6 address if the system only
has a localhost IPv6 address, but I don't know for a fact that this could
actually happen.

Did you consider dropping the AI_ADDRCONFIG but then decided against it
because it didn't work?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=111118&aid=3349356&group_id=11118

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Ijbswa-developers mailing list
Ijbswa-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ijbswa-developers


[prev in list] [next in list] [prev in thread] [next in thread]