inetd Overview

Source: UNIX Network Programming by W. Richard Stevens.

A typical scenario for this daemon:

1. On startup, it reads the /etc/inetd.conf file and creates a socket of the appropriate type (stream or datagram) for all the services specified in the file. Realize that there is a limit to the number of servers that inetd can be waiting for, as the total number of file descriptors used by inetd can't exceed the system's per-process limit. On most BSD systems, this limit is 64, but it can be changed by reconfiguring the kernel.

2. As each socket is created, a bind is executed for every socket, specifying the well-known address for the server. This TCP or UDP port number is obtained by looking up the service-name field from the configuration file in the /etc/services file. Some typical lines in the file, corresponding to the example lines in the configuration file that we showed above, are

       ftp         21/tcp
       telnet      23/tcp
       tftp        69/udp
       login       513/tcp
   

   Both the service-name (such as telnet) and the protocol from the inetd configuration file are passed as arguments to the library function getservbyname, to locate the correct port number for the bind. (We describe the getservbyname function in Section 8.2.)

3. For stream sockets, a listen is executed, specifying a willingness to receive connections on the socket and the queue length for incoming connections. This step is not done for datagram sockets.

4. A select is then executed, to wait for the first socket to become ready for reading. Recall from our description of this system call in Section 6.13, that a stream socket is considered ready for reading when a connection request arrives for that socket. A datagram socket is ready for reading when a datagram arrives. At this point the inetd daemon just waits for the select system call to return.

5. When a socket is ready for reading, if it is a stream socket, an accept system call is executed to accept the connection.

6. The inetd daemon forks and the child process handles the service request. The child closes all the file descriptors other than the socket descriptor that it is handling and then calls dup2 to cause the socket to be duplicated on file descriptors 0, 1, and 2. The original socket descriptor is then closed. Doing this, the only file descriptors that are open in the child are 0, 1, and 2. It then calls getpwnam to get the password file entry for the login-name that is specified in the /etc/inetd.conf file. If this entry does not have a user ID of zero (the superuser) then the child becomes the specified user by executing the setgid and setuid system calls. (Since the inetd process is executing with a user ID of zero, the child process inherits this user ID across the fork, so it is able to become any user that it chooses.) The child process now does an exec to execute the appropriate server-program to handle the request, passing the arguments that are specified in the configuration file.

7. If the socket is a stream socket, the parent process must close the connected socket. The parent goes back and executes the select system call again, waiting for the next socket to become ready for reading.

   ---