Sometime Today, Kishor Bhagwat assembled some asciibets to say:

rite../etc/services just lists the services...its the /etc/inetd.conf that defines which ones will be run(IF ur running

And that's not the only file. Many daemons may run standalone as well. To continue with the subject, anyone interested should probably read /usr/[share/]doc/tcp_wrappers/*

In brief:

tcp wrappers basically implement some sort of control at the tcp layer.

Inetd:

Inetd (now xinetd) is what is known as a super server. It listens on many different ports. These would be configured in /etc/inetd.conf. When a connection comes in on one of these ports, inetd starts the daemon that is supposed to service that service.

For example:

When one telnets to a machine, inetd is listening on port 23. When the connection comes in, inetd will start the telnet daemon.

The advantage of such a set up is twofold.

1. Only one server runs all the time, and others are spawned only when required. The overhead of spawning a new process isn't that much, since if the server were running on its own, it would have to spawn a child anyway.

2. Other servers do not have to have complex socket code built into them. They communicate through stdio. Inetd connects the socket to the child process' stdin and stdout descriptors before spawning.

So where does tcpd come in?

Instead of directly starting the server, inetd can start tcpd, and tell tcpd to start the correct server after performing any checks, etc. that it wants. If one opens /etc/inetd.conf, one will find against the telnet and ftp lines that the daemon to be spawned is tcpd with in.telned/in.ftpd as arguments.

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

Don't worry about the other values on the line, you'll figure them out soon enough.

Now, in execve parlance, the first argument passed in the argument vector corresponds to argv[0], i.e., the name that the program should call itself. tcpd takes this hint, and calls itself in.telnetd (which is what will show up if you do list running processes). It performs its checks, and then execs in.telnetd, passing all file descriptors on.

Thus, we have tcpd, which has a single access control file, doing checks for most daemons. Further more, since tcpd comes into the picture only while a connection is being estabilished, and leaves the scene thereafter, there is no overhead involved (except for that during checking, which is what we want).

Now, not all servers are started through inetd. Many, like sendmail, apache, and sshd, run as standalone servers. These servers can have tcpd compiled into them using libwrap.a and tcpd.h. They will then automatically check with hosts.allow and hosts.deny.

Now all these options must be selected while compiling tcpd and libwrap, but the defaults are decently secure anyway.

For info on the hosts.{allow,deny} files, check the man pages on hosts_access(5) and hosts_options(5). Also check the man pages on tcpd(8).

To check the configuration of your tcpd wrappers, use /sbin/tcpdchk. Give it the -v flag for more information.

Philip