1 .\" Copyright (c) 1985, 1991, 1993, 1994
2 .\" The Regents of the University of California. All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 3. All advertising materials mentioning features or use of this software
13 .\" must display the following acknowledgement:
14 .\" This product includes software developed by the University of
15 .\" California, Berkeley and its contributors.
16 .\" 4. Neither the name of the University nor the names of its contributors
17 .\" may be used to endorse or promote products derived from this software
18 .\" without specific prior written permission.
20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32 .\" from: @(#)inetd.8 8.3 (Berkeley) 4/13/94
50 .Op Fl a Ar address | hostname
53 .Op Ar configuration file
58 should be run at boot time by
62 It then listens for connections on certain
63 internet sockets. When a connection is found on one
64 of its sockets, it decides what service the socket
65 corresponds to, and invokes a program to service the request.
66 The server program is invoked with the service socket
67 as its standard input, output and error descriptors.
71 continues to listen on the socket (except in some cases which
72 will be described below). Essentially,
74 allows running one daemon to invoke several others,
75 reducing load on the system.
77 The following options are available:
78 .Bl -tag -width indent
82 Turn on logging of successful connections.
84 Turn on TCP Wrapping for external services.
86 .Sx "IMPLEMENTATION NOTES"
87 section for more information on TCP Wrappers support.
89 Turn on TCP Wrapping for internal services which are built in to
92 Specify the default maximum number of
93 simultaneous invocations of each service;
94 the default is unlimited.
95 May be overridden on a per-service basis with the "max-child"
98 Specify the default maximum number of times a service can be invoked
99 from a single IP address in one minute; the default is unlimited.
100 May be overridden on a per-service basis with the
101 "max-connections-per-ip-per-minute" parameter.
103 Specify the maximum number of times a service can be invoked
104 in one minute; the default is 256.
105 A rate of 0 allows an unlimited number of invocations.
107 Specify one specific IP address to bind to.
108 Alternatively, a hostname can be specified,
109 in which case the IPv4 or IPv6 address
110 which corresponds to that hostname is used.
111 Usually a hostname is specified when
115 in which case the hostname corresponds to the
119 When hostname specification is used
120 and both IPv4 and IPv6 bindings are desired,
121 one entry with the appropriate
123 type for each binding
124 is required for each service in
125 .Pa /etc/inetd.conf .
127 a TCP-based service would need two entries,
134 See the explanation of the
139 Specify an alternate file in which to store the process ID.
144 reads its configuration information from a configuration
145 file which, by default, is
146 .Pa /etc/inetd.conf .
147 There must be an entry for each field of the configuration
148 file, with entries for each field separated by a tab or
149 a space. Comments are denoted by a
152 of a line. There must be an entry for each field. The
153 fields of the configuration file are as follows:
155 .Bd -unfilled -offset indent -compact
159 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]]
160 user[:group][/login-class]
162 server program arguments
166 .Tn "ONC RPC" Ns -based
167 service, the entry would contain these fields:
169 .Bd -unfilled -offset indent -compact
173 user[:group][/login-class]
175 server program arguments
178 There are two types of services that
180 can start: standard and TCPMUX.
181 A standard service has a well-known port assigned to it;
182 it may be a service that implements an official Internet standard or is a
183 BSD-specific service.
186 TCPMUX services are nonstandard services that do not have a
187 well-known port assigned to them.
188 They are invoked from
190 when a program connects to the
192 well-known port and specifies
194 This feature is useful for adding locally-developed servers.
195 TCPMUX requests are only accepted when the multiplexor service itself
196 is enabled, above and beyond and specific TCPMUX-based servers; see the
197 discussion of internal services below.
201 entry is the name of a valid service in
204 or the specification of a
206 domain socket (see below).
209 services (discussed below), the service
212 be the official name of the service (that is, the first entry in
213 .Pa /etc/services ) .
214 When used to specify an
215 .Tn "ONC RPC" Ns -based
216 service, this field is a valid RPC service name in
219 The part on the right of the
221 is the RPC version number.
223 can simply be a single numeric argument or a range of versions.
224 A range is bounded by the low version to the high version -
226 For TCPMUX services, the value of the
228 field consists of the string
230 followed by a slash and the
231 locally-chosen service name.
232 The service names listed in
237 Try to choose unique names for your TCPMUX services by prefixing them with
238 your organization's name and suffixing them with a version number.
249 depending on whether the socket is a stream, datagram, raw,
250 reliably delivered message, or sequenced packet socket.
251 TCPMUX services must use
256 must be a valid protocol or
262 both of which imply IPv4 for backward compatibility.
277 specify that the entry accepts both IPv6 and IPv6 connections
281 If it is desired that the service is reachable via T/TCP, one should
284 which implies IPv4 for backward compatibility.
287 specifies IPv4 only, while
292 specify that the entry accepts both IPv6 and IPv6 connections
297 (for which only IPv4 is supported at this time)
298 are specified with the
303 TCPMUX services must use
312 entry specifies whether the server that is invoked by
315 the socket associated with the service access point, and thus whether
317 should wait for the server to exit before listening for new service
319 Datagram servers must use
321 as they are always invoked with the original datagram socket bound
322 to the specified service address.
323 These servers must read at least one datagram from the socket
325 If a datagram server connects
326 to its peer, freeing the socket so
328 can receive further messages on the socket, it is said to be
332 it should read one datagram from the socket and create a new socket
333 connected to the peer.
334 It should fork, and the parent should then exit
337 to check for new service requests to spawn new servers.
338 Datagram servers which process all incoming datagrams
339 on a socket and eventually time out are said to be
340 .Dq single-threaded .
345 are both examples of the latter type of
348 is an example of a multi-threaded datagram server.
350 Servers using stream sockets generally are multi-threaded and
354 Connection requests for these services are accepted by
356 and the server is given only the newly-accepted socket connected
357 to a client of the service.
358 Most stream-based services operate in this manner.
359 Stream-based servers that use
361 are started with the listening service socket, and must accept
362 at least one connection request before exiting.
363 Such a server would normally accept and process incoming connection
364 requests until a timeout.
365 TCPMUX services must use
368 The maximum number of outstanding child processes (or
372 service may be explicitly specified by appending a
374 followed by the number to the
378 (or if a value of zero is specified) there is no maximum.
380 once the maximum is reached, further connection attempts will be
381 queued up until an existing child process exits.
385 mode, although a value other than one (the
386 default) might not make sense in some cases.
387 You can also specify the maximum number of connections per minute
388 for a given IP address by appending
391 followed by the number to the maximum number of
392 outstanding child processes.
393 Once the maximum is reached, further
394 connections from this IP address will be dropped until the end of the
399 entry should contain the user name of the user as whom the server
400 should run. This allows for servers to be given less permission
406 allows to specify group name different
407 than default group for this user.
412 allows to specify login class different
419 entry should contain the pathname of the program which is to be
422 when a request is found on its socket. If
424 provides this service internally, this entry should
429 .Em server program arguments
430 should be just as arguments
431 normally are, starting with argv[0], which is the name of
432 the program. If the service is provided internally, the
434 of the service (and any arguments to it) or the word
436 should take the place of this entry.
438 Currently, the only internal service to take arguments is
440 Without options, the service will always return
441 .Dq ERROR\ : HIDDEN-USER .
442 The available arguments to this service that alter its behavior are:
443 .Bl -tag -width indent
453 option discussed below),
454 return this username instead of an error
456 for either socket credentials or the username.
460 return this username for every request.
461 This is primarily useful when running this service on a NAT machine.
464 the user's name to the ident requester,
466 username made up of random alphanumeric characters,
471 flag overrides not only the user names,
472 but also any fallback name,
478 .Ar sec Ns Op . Ns Ar usec
480 Specify a timeout for the service.
481 The default timeout is 10.0 seconds.
485 service, as per RFC 1413.
486 All the remaining flags apply only in this case.
488 Return numeric user IDs instead of usernames.
492 exists in the home directory of the identified user, report the username
493 found in that file instead of the real username.
494 If the username found in
496 is that of an existing user,
497 then the real username is reported.
500 flag is also given then the username in
502 is checked against existing user IDs instead.
506 but without the restriction that the username in
508 must not match an existing user.
512 exists in the home directory of the identified user, return
513 .Dq ERROR\ : HIDDEN-USER .
516 file which might exist.
520 instead of the name of the system as reported by
527 also provides several other
529 services internally by use of
530 routines within itself. These services are
534 (character generator),
536 (human readable time), and
538 (machine readable time, in the form of the number of seconds since
539 midnight, January 1, 1900). All of these services are available in
540 both TCP and UDP versions; the UDP versions will refuse service if the
541 request specifies a reply port corresponding to any internal service.
542 (This is done as a defense against looping attacks; the remote IP address
544 For details of these services, consult the
549 The TCPMUX-demultiplexing service is also implemented as an internal service.
550 For any TCPMUX-based service to function, the following line must be included
553 .Bd -literal -offset indent
554 tcpmux stream tcp nowait root internal
561 will log an entry to syslog each time a connection is accepted, noting the
562 service selected and the IP-number of the remote requester if available.
563 Unless otherwise specified in the configuration file,
564 and in the absence of the
577 rereads its configuration file when it receives a hangup signal,
579 Services may be added, deleted or modified when the configuration file
581 Except when started in debugging mode,
583 records its process ID in the file
584 .Pa /var/run/inetd.pid
585 to assist in reconfiguration.
586 .Sh IMPLEMENTATION NOTES
592 will wrap all services specified as
601 option is given, such
603 services will be wrapped.
604 If both options are given, wrapping for both
605 internal and external services will be enabled.
606 Either wrapping option
607 will cause failed connections to be logged to the
612 flag to the wrapping options will include successful connections in the
619 only wraps requests for a
621 service while no servers are available to service requests.
623 connection to such a service has been allowed,
626 over subsequent connections to the service until no more servers
627 are left listening for connection requests.
629 When wrapping is enabled, the
631 daemon is not required, as that functionality is builtin.
632 For more information on TCP Wrappers, see the relevant documentation
633 .Pq Xr hosts_access 5 .
634 When reading that document, keep in mind that
636 services have no associated daemon name.
637 Therefore, the service name
640 should be used as the daemon name for
645 describes the TCPMUX protocol:
646 ``A TCP client connects to a foreign host on TCP port 1. It sends the
647 service name followed by a carriage-return line-feed <CRLF>. The
648 service name is never case sensitive. The server replies with a
649 single character indicating positive (+) or negative (\-)
650 acknowledgment, immediately followed by an optional message of
651 explanation, terminated with a <CRLF>. If the reply was positive,
652 the selected protocol begins; otherwise the connection is closed.''
653 The program is passed the TCP connection as file descriptors 0 and 1.
655 If the TCPMUX service name begins with a
658 returns the positive reply for the program.
659 This allows you to invoke programs that use stdin/stdout
660 without putting any special server code in them.
662 The special service name
666 to list TCPMUX services in
669 The implementation includes a tiny hack
670 to support IPsec policy settings for each socket.
671 A special form of comment line, starting with
673 is interpreted as a policy specifier.
676 will be used as an IPsec policy string,
678 .Xr ipsec_set_policy 3 .
680 policy specifier is applied to all the following lines in
682 until the next policy specifier.
683 An empty policy specifier resets the IPsec policy.
685 If an invalid IPsec policy specifier appears in
688 will provide an error message via the
690 interface and abort execution.
691 .Ss Ux Domain Sockets
692 In addition to running services on IP sockets,
697 To do this you specify a
711 The specification of the socket must be
712 an absolute path name,
713 optionally prefixed by an owner and mode
715 .Em :user:group:mode: .
718 .Dl ":news:daemon:220:/var/run/sock"
720 creates a socket owned
725 with permissions allowing only that user and group to connect.
726 The default owner is the user that
729 The default mode only allows the socket's owner to connect.
736 must change the ownership and permissions on the socket.
737 This can only be done securely if
738 the directory in which the socket is created
739 is writable only by root.
744 to create sockets in world writable directories,
749 or a similar directory.
751 Internal services may be run on
753 domain sockets, in the usual way.
755 the name of the internal service
757 the last component of the socket's pathname.
759 .Bl -tag -width /var/run/inetd.pid -compact
760 .It Pa /etc/inetd.conf
763 translation of service names to RPC program numbers
765 translation of service names to port numbers
766 .It Pa /var/run/inetd.pid
767 the pid of the currently running
771 Here are several example service entries for the various types of services:
773 ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l
774 ntalk dgram udp wait root /usr/libexec/ntalkd ntalkd
775 telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd
776 shell stream tcp46 nowait root /usr/libexec/rshd rshd
777 tcpmux/+date stream tcp nowait guest /bin/date date
778 tcpmux/phonebook stream tcp nowait guest /usr/local/bin/phonebook phonebook
779 rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd
780 /var/run/echo stream unix nowait root internal
782 chargen stream tcp nowait root internal
789 logs error messages using
791 Important error messages and their explanations are:
795 .Ar service Ns / Ns Ar protocol
796 .No "server failing (looping), service terminated."
798 The number of requests for the specified service in the past minute
800 The limit exists to prevent a broken program
801 or a malicious user from swamping the system.
802 This message may occur for several reasons:
803 .Bl -enum -offset indent
805 There are many hosts requesting the service within a short time period.
807 A broken client program is requesting the service too frequently.
809 A malicious user is running a program to invoke the service in
810 a denial-of-service attack.
812 The invoked service program has an error that causes clients
819 as described above, to change the rate limit.
820 Once the limit is reached, the service will be
821 reenabled automatically in 10 minutes.
824 .Ar service Ns / Ns Ar protocol :
830 .Ar service Ns / Ns Ar protocol :
843 (re)reads the configuration file.
844 The second message occurs when the
857 The user or group ID for the entry's
861 .It "setsockopt(SO_PRIVSTATE): Operation not supported"
864 program attempted to renounce the privileged state associated with a
865 socket but was unable to.
868 .Xr ipsec_set_policy 3 ,
870 .Xr hosts_options 5 ,
885 .%A Michael C. St. Johns
886 .%T Identification Protocol
894 TCPMUX is based on code and documentation by Mark Lottor.
897 based services is modeled after that
901 The IPsec hack was contributed by the KAME project in 1999.
904 TCP Wrappers support first appeared in