1 .\" $NetBSD: inetd.8,v 1.57 2011/04/25 22:12:05 wiz Exp $
3 .\" Copyright (c) 1998 The NetBSD Foundation, Inc.
4 .\" All rights reserved.
6 .\" This code is derived from software contributed to The NetBSD Foundation
7 .\" by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
8 .\" NASA Ames Research Center.
10 .\" Redistribution and use in source and binary forms, with or without
11 .\" modification, are permitted provided that the following conditions
13 .\" 1. Redistributions of source code must retain the above copyright
14 .\" notice, this list of conditions and the following disclaimer.
15 .\" 2. Redistributions in binary form must reproduce the above copyright
16 .\" notice, this list of conditions and the following disclaimer in the
17 .\" documentation and/or other materials provided with the distribution.
19 .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
20 .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
21 .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
22 .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
23 .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
24 .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
25 .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
26 .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
27 .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
28 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
29 .\" POSSIBILITY OF SUCH DAMAGE.
31 .\" Copyright (c) 1985, 1991 The Regents of the University of California.
32 .\" All rights reserved.
34 .\" Redistribution and use in source and binary forms, with or without
35 .\" modification, are permitted provided that the following conditions
37 .\" 1. Redistributions of source code must retain the above copyright
38 .\" notice, this list of conditions and the following disclaimer.
39 .\" 2. Redistributions in binary form must reproduce the above copyright
40 .\" notice, this list of conditions and the following disclaimer in the
41 .\" documentation and/or other materials provided with the distribution.
42 .\" 3. Neither the name of the University nor the names of its contributors
43 .\" may be used to endorse or promote products derived from this software
44 .\" without specific prior written permission.
46 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
47 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
48 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
49 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
50 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
51 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
52 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
53 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
54 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
55 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
58 .\" from: @(#)inetd.8 8.4 (Berkeley) 6/1/94
72 .Op Ar configuration file
75 should be run at boot time by
79 It then opens sockets according to its configuration and listens
81 When a connection is found on one of its sockets, it decides what
82 service the socket corresponds to, and invokes a program to service
84 After the program is finished, it continues to listen on the socket
85 (except in some cases which will be described below).
88 allows running one daemon to invoke several others,
89 reducing load on the system.
91 The options available for
97 Turns on libwrap connection logging.
102 reads its configuration information from a configuration
103 file which, by default, is
104 .Pa /etc/inetd.conf .
105 The path given for this configuration file must be absolute, unless
108 option is also given on the command line.
109 There must be an entry for each field of the configuration
110 file, with entries for each field separated by a tab or
112 Comments are denoted by a ``#'' at the beginning of a line.
113 There must be an entry for each field (except for one
114 special case, described below).
115 The fields of the configuration file are as follows:
117 .Bd -unfilled -offset indent -compact
119 socket-type[:accept_filter]
120 protocol[,sndbuf=size][,rcvbuf=size]
124 server program arguments
129 based service, the entry would contain these fields:
131 .Bd -unfilled -offset indent -compact
134 rpc/protocol[,sndbuf=size][,rcvbuf=size]
138 server program arguments
141 To specify a UNIX-domain (local) socket, the entry would contain
144 .Bd -unfilled -offset indent -compact
147 unix[,sndbuf=size][,rcvbuf=size]
151 server program arguments
154 For Internet services, the first field of the line may also have a host
155 address specifier prefixed to it, separated from the service name by a colon.
156 If this is done, the string before the colon in the first field
157 indicates what local address
159 should use when listening for that service, or the single character
164 .Sq all local addresses .
165 To avoid repeating an address that occurs frequently, a line with a
166 host address specifier and colon, but no further fields, causes the
167 host address specifier to be remembered and used for all further lines
168 with no explicit host specifier (until another such line or the end of
172 is implicitly provided at the top of the file; thus, traditional
173 configuration files (which have no host address specifiers) will be
174 interpreted in the traditional manner, with all services listened for
175 on all local addresses.
179 entry is the name of a valid service in
184 services (discussed below), the service
187 be the official name of the service (that is, the first entry in
188 .Pa /etc/services ) .
189 When used to specify a
191 based service, this field is a valid RPC service name in
194 The part on the right of the
196 is the RPC version number.
197 This can simply be a single numeric argument or a range of versions.
198 A range is bounded by the low version to the high version \-
210 depending on whether the socket is a stream, datagram, raw,
211 reliably delivered message, or sequenced packet socket.
215 can be specified by appending a colon to the socket-type, followed by
216 the name of the desired accept filter.
219 will not see new connections for the specified service until the accept
220 filter decides they are ready to be handled.
224 must be a valid protocol as given in
232 Rpc based services are specified with the
240 will be recognized as
241 .Dq TCP or UDP over default IP version .
242 It is currently IPv4, but in the future it will be IPv6.
243 If you need to specify IPv4 or IPv6 explicitly, use something like
247 If you would like to enable special support for
256 In addition to the protocol, the configuration file may specify the
257 send and receive socket buffer sizes for the listening socket.
258 This is especially useful for
260 as the window scale factor, which is based on the receive socket
261 buffer size, is advertised when the connection handshake occurs,
262 thus the socket buffer size for the server must be set on the listen socket.
263 By increasing the socket buffer sizes, better
265 performance may be realized in some situations.
266 The socket buffer sizes are specified by appending their values to
267 the protocol specification as follows:
268 .Bd -literal -offset indent
271 tcp,rcvbuf=64k,sndbuf=1m
274 A literal value may be specified, or modified using
276 to indicate kilobytes or
278 to indicate megabytes.
279 Socket buffer sizes may be specified for all
280 services and protocols except for tcpmux services.
284 entry is used to tell
286 if it should wait for the server program to return,
287 or continue processing connections on the socket.
288 If a datagram server connects
289 to its peer, freeing the socket so
291 can receive further messages on the socket, it is said to be
294 server, and should use the
297 For datagram servers which process all incoming datagrams
298 on a socket and eventually time out, the server is said to be
307 are both examples of the latter type of
310 is an exception; it is a datagram server that establishes pseudo-connections.
313 in order to avoid a race;
314 the server reads the first packet, creates a new socket,
315 and then forks and exits to allow
317 to check for new service requests to spawn new servers.
320 suffix (separated from
324 by a dot or a colon) specifies the maximum number of server instances that may
327 within an interval of 60 seconds.
331 If it reaches this maximum spawn rate,
333 will log the problem (via the syslogger using the
338 and stop handling the specific service for ten minutes.
340 Stream servers are usually marked as
342 but if a single server process is to handle multiple connections, it may be
345 The master socket will then be passed as fd 0 to the server, which will then
346 need to accept the incoming connection.
347 The server should eventually time
348 out and exit when no more connections are active.
351 listen on the master socket for connections, so the server should not close
354 is usually the only stream server marked as wait.
358 entry should contain the user name of the user as whom the server should run.
359 This allows for servers to be given less permission than root.
360 Optionally, a group can be specified by appending a colon to the user name,
361 followed by the group name (it is possible to use a dot (``.'') in lieu of a
362 colon, however this feature is provided only for backward compatibility).
363 This allows for servers to run with a different (primary) group id than
364 specified in the password file.
365 If a group is specified and
367 is not root, the supplementary groups associated with that user will still be
372 entry should contain the pathname of the program which is to be
375 when a request is found on its socket.
378 provides this service internally, this entry should
383 .Em server program arguments
384 should be just as arguments
385 normally are, starting with argv[0], which is the name of
387 If the service is provided internally, the
390 should take the place of this entry.
391 It is possible to quote an argument using either single or double quotes.
392 This allows you to have, e.g., spaces in paths and parameters.
393 .Ss Internal Services
397 services internally by use of routines within itself.
402 (character generator),
404 (human readable time), and
406 (machine readable time,
407 in the form of the number of seconds since midnight, January 1, 1900 GMT).
408 For details of these services, consult the appropriate
411 TCP services without official port numbers can be handled with the
412 RFC1078-based tcpmux internal service.
413 TCPmux listens on port 1 for requests.
414 When a connection is made from a foreign host, the service name
415 requested is passed to TCPmux, which performs a lookup in the
416 service name table provided by
418 and returns the proper entry for the service.
419 TCPmux returns a negative reply if the service doesn't exist,
420 otherwise the invoked server is expected to return the positive
421 reply if the service type in
425 If the service type has the
428 TCPmux will return the positive reply for the
429 process; this is for compatibility with older server code, and also
430 allows you to invoke programs that use stdin/stdout without putting any
431 special server code in them.
432 Services that use TCPmux are
434 because they do not have a well-known port number and hence cannot listen
438 rereads its configuration file when it receives a hangup signal,
440 Services may be added, deleted or modified when the configuration file
444 .Em /var/run/inetd.pid
445 that contains its process identifier.
449 wrappers is included with
451 to provide internal tcpd-like access control functionality.
452 An external tcpd program is not needed.
453 You do not need to change the
455 server-program entry to enable this capability.
461 for access control facility configurations, as described in
466 wrappers do not affect/restrict
468 or internal services.
470 The implementation includes a tiny hack to support IPsec policy settings for
472 A special form of the comment line, starting with
474 is used as a policy specifier.
475 The content of the above comment line will be treated as a IPsec policy string,
477 .Xr ipsec_set_policy 3 .
478 Multiple IPsec policy strings may be specified by using a semicolon
480 If conflicting policy strings are found in a single line,
481 the last string will take effect.
484 line affects all of the following lines in
485 .Pa /etc/inetd.conf ,
486 so you may want to reset the IPsec policy by using a comment line containing
489 .Pq with no policy string .
491 If an invalid IPsec policy string appears in
492 .Pa /etc/inetd.conf ,
494 logs an error message using
496 and terminates itself.
497 .Ss IPv6 TCP/UDP behavior
498 If you wish to run a server for both IPv4 and IPv6 traffic,
499 you will need to run two separate processes for the same server program,
500 specified as two separate lines in
509 means TCP on top of the current default IP version,
510 which is, at this moment, IPv4.
512 Under various combination of IPv4/v6 daemon settings,
514 will behave as follows:
517 If you have only one server on
519 IPv4 traffic will be routed to the server.
520 IPv6 traffic will not be accepted.
522 If you have two servers on
526 IPv4 traffic will be routed to the server on
528 and IPv6 traffic will go to server on
531 If you have only one server on
533 only IPv6 traffic will be routed to the server.
534 The kernel may route to the server IPv4 traffic as well,
535 under certain configuration.
541 .Bl -tag -width /etc/hosts.allow -compact
542 .It Pa /etc/inetd.conf
543 configuration file for all
547 service name to protocol and port number mappings.
548 .It Pa /etc/protocols
549 protocol name to protocol number mappings
552 service name to service number mappings.
553 .It Pa /etc/hosts.allow
554 explicit remote host access list.
555 .It Pa /etc/hosts.deny
556 explicit remote host denial of service list.
560 .Xr hosts_options 5 ,
584 .%T "Discard Protocol"
591 .%T "Character Generator Protocol"
598 .%T "Daytime Protocol"
613 .%T "TCP port service Multiplexer (TCPMUX)"
622 based services is modeled after that
623 provided by SunOS 4.1.
624 Support for specifying the socket buffer sizes was added in
626 In November 1996, libwrap support was added to provide
627 internal tcpd-like access control functionality;
628 libwrap is based on Wietse Venema's tcp_wrappers.
629 IPv6 support and IPsec hack was made by KAME project, in 1999.
631 Host address specifiers, while they make conceptual sense for RPC
632 services, do not work entirely correctly.
633 This is largely because the portmapper interface does not provide
634 a way to register different ports for the same service on different
636 Provided you never have more than one entry for a given RPC service,
637 everything should work correctly (Note that default host address
638 specifiers do apply to RPC lines with no explicit specifier.)
641 on IPv6 is not tested enough.
642 .Sh SECURITY CONSIDERATIONS
648 built-in trivial services is not recommended because remote
649 users may abuse these to cause a denial of network service to
650 or from the local host.