in ce655fdac8 the getnameinfo function
was factored into a separate TU to prevent its POSIX signature from
colliding with GLIBC's wrong prototype. since this has been fixed
in GLIBC 10 years ago, it should be safe by now.
undoing the workaround has the advantage that all hooked functions
are now available in the same place, which is a prerequisite for
a change i'm about to commit.
if it turns out there's still systems in use that use the old GLIBC
version with the wrong prototype, we can add a configure check
dealing with it.
since many users complain about issues with modern, ultracomplex
clusterfuck software such as chromium, nodejs, etc, i've reconsidered
one of my original ideas how to implement remote dns lookup support.
instead of having a background thread serving requests via a pipe,
the user manually starts a background daemon process before running
proxychains, and the two processes then communicate via UDP.
this requires much less hacks (like hooking of close() to prevent
pipes from getting closed) and doesn't need to call any async-signal
unsafe code like malloc(). this means it should be much more compatible
than the previous method, however it's not as practical and slightly
slower.
it's recommended that the proxychains4-daemon runs on localhost, and
if you use proxychains-ng a lot you might want to set ip up as a service
that starts on boot. a single proxychains4-daemon should theoretically
be able to serve many parallel proxychains4 instances, but this has not
yet been tested so far. it's also possible to run the daemon on other
computers, even over internet, but currently there is no error-checking/
timeout code at all; that means the UDP connection needs to be very
stable.
the library code used for the daemon sources are from my projects
libulz[0] and htab[1], and the server code is loosely based on
microsocks[2]. their licenses are all compatible with the GPL.
if not otherwise mentioned, they're released for this purpose under
the standard proxychains-ng license (see COPYING).
[0]: https://github.com/rofl0r/libulz
[1]: https://github.com/rofl0r/htab
[2]: https://github.com/rofl0r/microsocks
When hardening flags are set by Debian's auto build system,
the project fails to build due to usage of -pie, which tells the linker
to build a PIE binary, and since the user LDFLAGS are deliberately put
later in the command line to override things, this overrides -shared.
work around by putting it directly in the last position of the linker
command line.
closes#124
Commit message authored by commiter.
the allocatorthread got pointers to RAM which were reallocated
behind the back, and if realloc() couldn't grow in-place, lead
to segfaults in applications that do a lot of DNS-lookups such
as webbrowsers.
closes#66closes#31
thanks to @ravomavain for tracking down the issue.
the hostentdb introduced between 4.2 and 4.3
(via af5c6f0c6a )
had several issues:
- it caused breakage on FreeBSD and was commented out there
- prevented usage of the hostdb when proxy_dns was turned off
(issue #42)
- required dynamic memory allocation which was accessed from several
threads
- wouldnt reflect changes to the hosts file made during program run
the only sensible solution is to remove the hostentdb and replace it
with a home-grown hosts parser (we can't use gethostent() since
that would mess up the gethostent()-state from different threads).
the new parser used here is deliberately held simple and only meant
to provide the user with means to reference hardcoded ipv4 addresses
via his hosts file.
fixes#42
this bug was fixed shortly before 2.14 release, so we checked for that.
however some distros decided to backport this fix to earlier versions,
breaking our compiletime check.
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e4ecafe004b3d4270b3a9dace8f970047400ed38
the portable solution is to stick the function into a separate comilation
unit that does not see the glibc prototype.
closes#7
the central dns resolver function proxy_gethostbyname() used
to iterate over the gethostent() db (/etc/hosts) on each dns
request.
since this is not threadsafe, we synchronized access to it
previously using mutexes. the parsing of this file is slow,
and blocking all threads to do it even moreso.
since gethostent_r() is only available on a few platforms,
i decided to read the hostent db once and then use a quick
in-memory lookup on further usage.
+ some further refactoring.
instead of allocating memory in the child, we now use the allocator
thread to do all the necessary allocations himself.
additionally we provide a clean API to query the ip <-> dns mapping.
these functions connect via a pipe to the allocator thread, and
exchange messages.
further cleanup is needed, but it seems to work so far.
thread-safety is not yet guaranteed.
closes#1
this is in order to get irssi, which forks for DNS lookups,
and similar programs, to work as intended.
in a previous attempt i learned that shared memory created in a
child process is not visible to the parent;
in this attempt i spin off a thread from the parent which listens
on a pipe and manages the shared memory allocation from the parent
address-space. however this doesnt work as expected:
memory allocated in the parent after the child forked is not visi-
ble to the child as well.
so what happens is: irssi starts a child process, the thread allocs
memory and hands it to the child, the child attempts to write and
segfaults. however irssi doesnt crash. since now the memory is
already allocated, doing the dns lookup again will succeed.
i.e. the dns lookup works now in irssi by luck.
all but the first dns lookups will suceed.
however this is not good enough for me to be satisfied, i commit
this only for documentation purposes.
for some reason, the linker needs --no-as-needed for both
libdl and libpthread.
closes#4
thanks to @tomsawyer for discovering this.
the proposed -pthread change was not needed though,
and this is a good thing since it seems not portable.
Zenithal