tcp wrappers and rpc.statd

Paul Lussier p.lussier at comcast.net
Wed Aug 2 05:29:01 EDT 2006


Hi all,

Has anyone ever used tcp wrappers to explicitly control access to rpc.statd?
The man page for statd (at least on Debian) states that:

  TCP_WRAPPERS SUPPORT

    This rpc.statd version is protected by the tcp_wrapper
    library. You have to give the clients access to rpc.statd if they
    should be allowed to use it.  To allow connects from clients of
    the .bar.com domain you could use the following line in
    /etc/hosts.allow:

    statd: .bar.com

    You have to use the daemon name statd for the daemon name (even if
    the binary has a different name).

    For further information please have a look at the tcpd(8) and
    hosts_access(5) manual pages.


So, theoretically, it appears that just placing a line like this in
/etc/hosts.allow should do what I want:

 statd:  10.0.123.0/255.255.255.0, 10.0.124.0/255.255.255.0

Yet, there's nothing anywhere that I can see that ever invokes tcpd to
wrap around the execution of statd.  I'm quite familiar with wrapping
a daemon exec'ed from within inetd where you write something like:

  finger  stream  tcp   nowait  nobody  /usr/sbin/tcpd  /usr/sbin/in.fingerd

Doing on nmap of the system in question shows statd running when
probing the 10.0.20.31 interface.  Adding the line to /etc/hosts.allow
does nothing.  But when I hack the init.d script to "wrap" statd with
tcpd, things seemt to work as expected.  Unfortunately, to do *that*
means I also have to shove it in the background with & which means
that the init script doesn't work for stop or restart for some reason
(haven't investigated this part too much).  However, wrapping it like
this does in fact prevent statd from being seen on any interface
except those on 10.0.2[34].X .

Any ideas?
-- 
Seeya,
Paul



More information about the gnhlug-discuss mailing list