[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Got a puzzle here



On Monday 04 November 2019 08:50:20 Greg Wooledge wrote:

> On Fri, Nov 01, 2019 at 06:46:25PM -0400, Gene Heskett wrote:
> > I'll make sure its installed. Right now. But that is a problem:
> > root@coyote:etc$ apt install tcpwrappers
>
> ... no, Gene.
>
> TCP wrappers is a *library*, and its package name in Debian is
> libwrap0.
>
Already installed, claims latest version.

> wooledg:~$ apt-cache search tcp wrappers
> fakeroot - tool for simulating superuser privileges
> libfakeroot - tool for simulating superuser privileges - shared
> libraries libauthen-libwrap-perl - module providing access to the TCP
> Wrappers library python-tcpwrap - Python interface for libwrap0 (TCP
> wrappers) ruby-proxifier - add support for HTTP or SOCKS proxies
> sendmail - powerful, efficient, and scalable Mail Transport Agent
> (metapackage) sendmail-bin - powerful, efficient, and scalable Mail
> Transport Agent libwrap0 - Wietse Venema's TCP wrappers library
> libwrap0-dev - Wietse Venema's TCP wrappers library, development files
> ucspi-tcp - command-line tools for building TCP client-server
> applications ucspi-tcp-ipv6 - command-line tools for building TCP
> client-server applications (IPv6)
>
> (At least learn how to use the basic Debian utilities.)
>
> A given program is either built with libwrap, or it isn't.  You can't
> just install it and have it affect programs that aren't built to use
> it.
>
> (It actually has a second mode of operation, though -- in a service
> manager like inetd or xinetd, you can use TCP wrappers as an actual
> wrapper program that inetd invokes.  Then the wrapper can validate
> whether it wants to continue this connection or not, and if it chooses
> to allow the connection, it will exec the actual daemon that it's
> wrapping, e.g. in.ftpd or in.telnetd or some other relic of the bronze
> age.)
>
> (None of this applies to Apache, which is NOT linked with libwrap0,
> and which is NOT launched by a service manager.  It's a standalone
> daemon that does its own socket listening, so there's no place to
> insert a chain-loading wrapper program.)

If its not built to use libwrap0, then I assume it has its own module to 
similarly restrict its response to a specified incoming source address?

And it is?

Thanks.

Gene Heskett


Reply to: