INETD(1M) INETD(1M) NAME inetd - Internet ``super-server'' SYNOPSIS /usr/etc/inetd [ -R rate ] [ -d ] [ -l qlen ] [ -s ] [ -X extended configuration file ] [ -t {on|off|all}[:{accept|reject}] ] [ -S {on|off|all|wrap} ] [ configuration-file ] DESCRIPTION When inetd is started at boot time by /etc/init.d/network, it reads its configuration information from the /etc/inetd.conf and listens for connections on certain internet sockets. When a connection is found on one of its sockets, it decides what service the socket corresponds to, and invokes a program to service the request. After the program is finished, it continues to listen on the socket (except in some cases which will be described below). Essentially, inetd allows running one daemon to invoke several others, reducing load on the system. OPTIONS -R This option controls the maximum number of times a service can be invoked in one minute; the default is 1000. -d This option turns on debugging information. Note that this can confuse some applications; use this cautiously. -f This option is no longer supported and will simply cause a warning message to be included in the syslog if used. -l This option changes the listen queue length used for TCP sockets. By default this value is 255. -s Causes inetd to just parse the configuration file (default is /etc/inetd.conf) and report any errors. Do not need superuser privileges to run inetd using this option. -X This option is used to specify an alternate extended configuration file (default is /etc/inetd.conf.sec). -t Controls when inetd uses tcp_wrappers(8) to accept or deny access to services using hosts_access(5). This option may take the following values: off This is the default. on Only services marked with the prefix '!' in the specified or default inetd configuration file are controlled by tcp_wrappers. You can control ``internal'' service using this prefix, including the tcpmux service. all All services (including ``internal'') are controlled by tcp_wrappers. No special prefix is required. NOTE: See TCP_WRAPPERS configuration section for details. It is also possible to set the default accept/reject behavior when an ERROR occurs when performing tcp_wrapper processing. These errors can be related to configuration and system resource problems. The default policy can be set by appending either :accept(Default=accept) or :reject to the the -t command-line flag. For example, -t on:reject would reject the connection when there's an error. PLEASE NOTE This does not set or change the default policy where a service is not defined in /etc/hosts.allow or /etc/hosts.deny files. -S Causes inetd to set a new session id ( setsid(2) ), when forking a service, according to the following table below: off This is the default. The forked service ( ftpd for example ) inherits the session id from inetd and, therefore, has the same process group id of inetd. This may not be true if the service calls setsid() itself. on Services marked with the prefix '@' in inetd configuration file ( /etc/inetd.conf ) have a their own session id. all All services ( including ``internal'' ) have a their own session id. wrap Enable ``setsid'' feature only for ``tcp_wrappe'd'' services enabled via the ``-t'' switch. NOTE: When the ``set session id'' feature is used, the forked service does not have the same process group id of inetd and a direct consequence is the command ``killall -g inetd'' will not send the signals to the child of inetd where that feature has been used. To specify a different configuration file or use different options, put configurations parameters in the file /etc/config/inetd.options. Any empty lines or lines starting with a ``#'' are ignored. CONFIGURATION FILE Each line of the configuration file must be a valid service or a comment. Comments are denoted by a ``#'' at the beginning of a line. Each field in a line must be specified, with values for each field separated by a tab or a space. The fields are as follows: service name socket type protocol wait/nowait user server program server program arguments There are three types of services that inetd can start: standard, RPC and TCPMUX. A standard service has a well-known port assigned to it and is listed in /etc/services or the NIS services map (see services(4)); it may be a service that implements an official Internet standard or is a BSD Unix-specific service. RPC services use the Sun RPC calls as the transport; such services are listed in /etc/rpc or the NIS rpc map (see rpc(4)). TCPMUX services are nonstandard services that do not have a well-known port assigned to them. They are invoked from inetd when a program connects to the ``tcpmux'' well-known port and specifies the service name. This feature is useful for adding locally-developed servers. For standard Internet services, the service name field is the name of a valid service in the services(4) database. For ``internal'' services (discussed below), the service name must be the official name of the service (that is, the first field in /etc/services). For RPC services, the value of the service name field consists of the RPC service name, followed by a slash and either a version number or a range of version numbers (e.g., mountd/1). For TCPMUX services, the value of the service name field consists of the string ``tcpmux'' followed by a slash and the locally-chosen service name. If the service name begins with a ``+'', it indicates inetd will handle the initial handshake with the requesting program, otherwise the service is responsible for the handshake. (The handshake is described in the inetd section in the IRIX Network Programming Guide.) The service names listed in /etc/services and the name ``help'' are reserved. The ``help'' name causes inetd to list available TCPMUX services. Private protocols should use a service name that has a high chance of being unique. A good practice is to prefix the service name with the name of your organization. Multiple versions of a protocol can suffix the service name with a protocol version number. The socket type should be one of ``stream'', ``dgram'', or ``raw'', depending on whether the socket is a stream, datagram, or raw socket. TCPMUX services must use ``stream.'' The protocol must be a valid protocol. Examples are ``tcp'' and ``udp'', both of which imply IPv4 for backward compatability. The protocols ``tcp4'' and ``udp4'' specify IPv4 only; ``tcp6'' and ``udp6'' imply IPv6 only. The protocols ``tcp46'' and ``udp46'' indicate that the service should accept requests that arrive via IPv4 or IPv6. When ``tcp46'' or ``udp46'' is specified, IPv4 requests arrive via IPv4-mapped IPv6 addresses. For RPC services, the field consists of the string ``rpc'' followed by a slash and a specification of the transport protocol ,e.g., rpc/tcp, rpc/tcp4, rpc/tcp6, rpc/udp, rpc/udp4, etc. Note that ``tcp46'' and ``udp46'' should be avoided with RPC services, see the NOTES section below. If 2 RPC services use the same server program with different protocols, such as tcp and udp, the 2 services need to appear in protocol lexicographic order. TCPMUX services must use ``tcp'', ``tcp4'', ``tcp6'' or ``tcp46''. The wait/nowait entry specifies whether the server that is invoked by inetd will take over the socket associated with the service access point, and thus whether inetd should wait for the server to exit before listening for new service requests. Datagram servers must use wait, as they are always invoked with the original datagram socket bound to the specified service address. These servers must read at least one datagram from the socket before exiting. If a datagram server connects to its peer, freeing the socket so inetd can received further messages on the socket, it is said to be a ``multi-threaded'' server; it should read one datagram from the socket and create a new socket connected to the peer. It should fork, and the parent should then exit to allow inetd to check for new service requests to spawn new servers. Datagram servers which process all incoming datagrams on a socket and eventually time out are said to be single-threaded. Talkd(8) is an example of the single- threaded datagram server. Tftpd(8) is an example of a multi-threaded datagram server. Servers using stream sockets generally are multi-threaded and use the nowait entry. Connection requests for these services are accepted by inetd, and the server is given only the newly-accepted socket connected to a client of the service. Most stream-based services operate in this manner. Stream-based servers that use wait are started with the listening service socket, and must accept at least one connection request before exiting. Such a server would normally accept and process incoming connection requests until a timeout. RPC services usually wait. TCPMUX services must use nowait. The user field should contain the user name of the user as whom the server should run. This allows for servers to be given less permission than root. The server program field should contain the pathname of the program which is to be executed by inetd when a request is found on its socket. If inetd provides this service internally, this field should be ``internal''. For non-internal services, the arguments to the server program should be just as they normally are, starting with argv[0], which is the name of the program. There is a limit of 11 arguments per program (including argv[0]). The following combination of prefixes, placed just before the server program pathname, causes the following options to be turned on according to the following table: ? Suppress error logging of a missing server. As shipped, /etc/inetd.conf uses `?' to suppress error logging for servers that are included in optional software packages. ! When tcp_wrappers options is enabled via `-t on', host access to the service can be enable by prefixing the pathname with a '!'. @ When the ``set session id'' option is enabled via `-S on', a new session id is created for the forked service. Inetd provides several trivial services internally by use of routines within itself. These services are ``echo'', ``discard'', ``chargen'' (character generator), ``daytime'' (human readable time), ``time'' (machine readable time, in the form of the number of seconds since midnight, January 1, 1900), and ``tcpmux'' (service multiplexor). All of these services are TCP-based. For details of these services, consult RFCs 862, 863, 864, 867, 868, and 1078. Inetd rereads its configuration file when it receives a hangup signal, SIGHUP. Services may be added, deleted or modified when the configuration file is reread. To disable a service, add the comment character ``#'' at the beginning of the service's line in inetd.conf and send SIGHUP to inetd with the command /etc/killall -HUP inetd Inetd supports an additional extended configuration file. Each entry of this configuration file must be a valid service or a comment. Comments are denoted by a ``#'' at the beginning of a line. The format of each entry is a service name followed by any number of name-value pairs separated by tabs or spaces. If the service name doesn't match an entry in inetd.conf then the entry is ignored. Each name-value pair consists of a feature name, followed by an '=' and the value of that feature. Undefined feature names are ignored. The only feature name currently supported is 'cap' which is used to specify the capability set to invoke the service daemon with. For RPC services inetd respects the mapping of RPC program numbers to UDP or TCP ports defined in the /etc/rpcports file. TCP_WRAPPERS configuration and implementation All services ( including TCPMUX and internal ) services can be controlled by the tcp_wrappers switch -t. To control them, use the following ``server'' entries for configuring the hosts_access(5) file: o Use the ``service name'' itself. For connecting to the TCPMUX service, use ``tcpmux''. o To control a specific tcpmux service, use the name of the service (i.e. what is listed after tcpmux/). For example, ``sgi_printer''. o To control access to the TCPMUX ``help'' service, use the name ``tcpmux_help''. Please note only stream/nowait and dgram services can be controlled via the tcp_wrappers feature. See tcp_wrappers(8) manual pages for details. ERROR MESSAGES Inetd logs error messages using syslog(3B). Important error messages and their explanations are: service/protocol server failing (looping), service terminated. The number of requests for the specified service in the past minute exceeded the limit. The limit exists to prevent a broken program or a malicious user from swamping the system. This message may occur for several reasons: 1) there are lots of hosts requesting the service within a short time period, 2) a 'broken' client program is requesting the service too frequently, 3) a malicious user is running a program to invoke the service in a 'denial of service' attack, or 4) the invoked service program has an error that causes clients to retry quickly. Use the -R option, as described above, to change the rate limit. Once the limit is reached, the service will be reenabled automatically in 10 minutes. service/protocol: No such user 'user', service ignored service/protocol: getpwnam: user: No such user No entry for user exists in the passwd file. The first message occurs when inetd (re)reads the configuration file. The second message occurs when the service is invoked. service: can't set uid number service: can't set gid number The user or group ID for the entry's user is invalid. too many services: open-file limit reached. The number of services in the configuration file exceeds the number of file descriptors that inetd can keep open. Unnecessary services must be removed or commented out or the kernel must be reconfigured to increase the limit (the NOFILES parameter in /var/sysgen/master.d/kernel.) service/protocol: all allowed ports in use. Rules in the /etc/rpcports file specified a range of ports for the service, but all the ports in that range were already bound to other sockets. Inetd will fall back to using any non-reserved port for the service. EXAMPLES Here are several example service entries for the various types of services ftp stream tcp6 nowait root /usr/etc/ftpd ftpd -l ntalk dgram udp wait root /usr/etc/talkd talkd rusersd/1 dgram rpc/udp wait root /usr/etc/rpc.rusersd rusersd tcpmux/+date stream tcp nowait guest /bin/date date Here another example where (1) tcpmux is controlled by hosts_access if inetd command-line options ``-t'' is turned on (2) tcpmux and setsid() ( if command-line options ``-S'' is turned on ) are utilized for rshd. Also, if /usr/etc/rshd is not present, inetd will not output an error message in SYSLOG. tcpmux stream tcp nowait root !internal echo stream tcp nowait root internal shell stream tcp6 nowait root !@?/usr/etc/rshd rshd -L Here is an example entry for the extended configuration file exec cap=CAP_SETUID,CAP_SETGID,CAP_SETPCAP+ip NOTE If NIS is enabled on your system, inetd uses the NIS equivalents of /etc/services and /etc/rpc. Make sure your NIS server's services and rpc databases contain the entries listed in these files. NOTES inetd has a limit of 512 characters per line of the configuration file. Exceeding this limit may cause inetd to terminate abnormally. If both TCP and UDP services are listed for an RPC service, the TCP service should be listed first. Since IRIX 6.5.22, RPC services are bound after all non-RPC services. This prevents occasional collision when RPC services grabs a port reserved by a non-RPC service. Using a protocol value of ``udp46'' or ``tcp46'' for RPC services can lead to unexpected problems because a udp4 or tcp4 service can also be bound to the same port and divert traffic from the udp46 or tcp46 socket. Instead of using ``udp46'' RPC services should be listed in two separate entries, one with a protocol of ``udp'' and another with a protocol of ``udp6''. Likewise, use two entries with ``tcp'' and ``tcp6'' instead of one entry with ``tcp46''. As of IRIX 6.5.26, inetd will attempt to use the rpcbind(1M) protocol to register RPC services, and will fall back to portmap(1M) if rpcbind is not running. SEE ALSO ftpd(1M), rexecd(1M), rlogind(1M), rshd(1M), telnetd(1M), tftpd(1M), rpcports(4), tcp_wrappers(8), hosts_access(5), setsid(2). sockets programming chapter in the IRIX Network Programming Guide. RFCs are available from the Network Information Center at SRI International, Menlo Park, CA. Page 8