Provided by: xinetd_2.3.15.4-3build1_amd64 
NAME
xinetd.conf - Extended Internet Services Daemon configuration file
DESCRIPTION
xinetd.conf is the configuration file that determines the services provided by xinetd.
Any line whose first non-white-space character is a '#' is considered a comment line.
Empty lines are ignored.
The file contains entries of the form:
service <service_name>
{
<attribute> <assign_op> <value> <value> ...
...
}
The assignment operator, assign_op, can be one of '=', '+=', '-='. The majority of
attributes support only the simple assignment operator, '='. Attributes whose value is a
set of values support all assignment operators. For such attributes, '+=' means adding a
value to the set and '-=' means removing a value from the set. A list of these attributes
will be given after all the attributes are described.
Each entry defines a service identified by the service_name. The following is a list of
available attributes:
id This attribute is used to uniquely identify a service. This is useful
because there exist services that can use different protocols and need to
be described with different entries in the configuration file. By
default, the service id is the same as the service name.
type Any combination of the following values may be used:
RPC if this is an RPC service
INTERNAL if this is a service provided by xinetd.
TCPMUX/TCPMUXPLUS
if this is a service that will be started according to the
RFC 1078 protocol on the TCPMUX well-known port. See the
section describing TCPMUX services below.
UNLISTED if this is a service not listed in a standard system file
(like /etc/rpc for RPC services, or /etc/services for non-RPC
services).
flags Any combination of the following flags may be used:
INTERCEPT Intercept packets or accepted connections in order to verify
that they are coming from acceptable locations (internal or
multi-threaded services cannot be intercepted).
NORETRY Avoid retry attempts in case of fork failure.
IDONLY Accept connections only when the remote end identifies the
remote user (i.e. the remote host must run an identification
server). This flag applies only to connection-based
services. This flag is ineffective if the USERID log option
is not used.
NAMEINARGS This will cause the first argument in "server_args" to be
argv[0] when executing the server, as specified in "server".
This allows you to use tcpd by putting tcpd in "server" and
the name of the server in "server_args" like in normal inetd.
NODELAY If the service is a tcp service and the NODELAY flag is set,
then the TCP_NODELAY flag will be set on the socket. If the
service is not a tcp service, this option has no effect.
KEEPALIVE If the service is a tcp service and the KEEPALIVE flag is
set, then the SO_KEEPALIVE socket flag will be set on the
socket. If the service is not a tcp service, this option has
no effect.
NOLIBWRAP This disables internal calling of the tcpwrap library to
determine access to the service. This may be needed in order
to use libwrap functionality not available to long-running
processes such as xinetd; in this case, the tcpd program can
be called explicitly (see also the NAMEINARGS flag). For RPC
services using TCP transport, this flag is automatically
turned on, because xinetd cannot get remote host address
information for the rpc port.
SENSOR This replaces the service with a sensor that detects accesses
to the specified port. NOTE: It will NOT detect stealth
scans. This flag should be used only on services that you
know you don't need. When an access is made to this service's
port, the IP Address is added to a global no_access list.
This causes all subsequent accesses from the originating IP
address to be denied access until the deny_time setting
expires. The amount of time spent on this list is
configurable as the deny_time attribute. The SENSOR flag will
also cause xinetd to consider the server attribute to be
INTERNAL no matter what is typed on the same line. Another
important thing to remember is that if the socket_type is set
to stream, then the wait attribute should be set to no.
IPv4 Sets the service to be an IPv4 service (AF_INET).
IPv6 Sets the service to be an IPv6 service (AF_INET6), if IPv6 is
available on the system.
LABELED The LABELED flag will tell xinetd to change the child
processes SE Linux context to match that of the incoming
connection as it starts the service. This only works for
external tcp non-waiting servers and is an error if applied
to an internal, udp, or tcp-wait server.
REUSE The REUSE flag is deprecated. All services now implicitly
use the REUSE flag.
v6only This is boolean "yes" or "no". This will result in a service accepting
only IPv6 connections, instead of both IPv6 and IPv4 connections. The
default is determined by the "bindv6only" kernel variable.
disable This is boolean "yes" or "no". This will result in the service being
disabled and not starting.
socket_type Possible values for this attribute include:
stream stream-based service
dgram datagram-based service
raw service that requires direct access to IP
seqpacket service that requires reliable sequential datagram
transmission
protocol determines the protocol that is employed by the service. The protocol
must exist in /etc/protocols. If this attribute is not defined, the
default protocol employed by the service will be used.
wait This attribute determines if the service is single-threaded or
multi-threaded and whether or not xinetd accepts the connection or the
server program accepts the connection. If its value is yes, the service
is single-threaded; this means that xinetd will start the server and then
it will stop handling requests for the service until the server dies and
that the server software will accept the connection. If the attribute
value is no, the service is multi-threaded and xinetd will keep handling
new service requests and xinetd will accept the connection. It should be
noted that udp/dgram services normally expect the value to be yes since
udp is not connection oriented, while tcp/stream servers normally expect
the value to be no.
user determines the uid for the server process. The user attribute can either
be numeric or a name. If a name is given (recommended), the user name
must exist in /etc/passwd. This attribute is ineffective if the
effective user ID of xinetd is not super-user.
group determines the gid for the server process. The group attribute can either
be numeric or a name. If a name is given (recommended), the group name
must exist in /etc/group. If a group is not specified, the group of user
will be used (from /etc/passwd). This attribute is ineffective if the
effective user ID of xinetd is not super-user and if the groups attribute
is not set to 'yes'.
instances determines the number of servers that can be simultaneously active for a
service (the default is no limit). The value of this attribute can be
either a number or UNLIMITED which means that there is no limit.
nice determines the server priority. Its value is a (possibly negative)
number; check nice(3) for more information.
server determines the program to execute for this service.
server_args determines the arguments passed to the server. In contrast to inetd, the
server name should not be included in server_args.
libwrap overrides the service name passed to libwrap (which defaults to the
server name, the first server_args component with NAMEINARGS, the id for
internal services and the service name for redirected services). This
attribute is only valid if xinetd has been configured with the libwrap
option.
only_from determines the remote hosts to which the particular service is available.
Its value is a list of IP addresses which can be specified in any
combination of the following ways:
a) a numeric address in the form of %d.%d.%d.%d. If the rightmost
components are 0, they are treated as wildcards (for example,
128.138.12.0 matches all hosts on the 128.138.12 subnet). 0.0.0.0
matches all Internet addresses. IPv6 hosts may be specified in the
form of abcd:ef01::2345:6789. The rightmost rule for IPv4 addresses
does not apply to IPv6 addresses.
b) a factorized address in the form of %d.%d.%d.{%d,%d,...}. There is
no need for all 4 components (i.e. %d.%d.{%d,%d,...%d} is also ok).
However, the factorized part must be at the end of the address.
This form does not work for IPv6 hosts.
c) a network name (from /etc/networks). This form does not work for
IPv6 hosts.
d) a host name. When a connection is made to xinetd, a reverse lookup
is performed, and the canonical name returned is compared to the
specified host name. You may also use domain names in the form of
.domain.com. If the reverse lookup of the client's IP is within
.domain.com, a match occurs.
e) an ip address/netmask range in the form of 1.2.3.4/32. IPv6
address/netmask ranges in the form of 1234::/46 are also valid.
Specifying this attribute without a value makes the service available to
nobody.
no_access determines the remote hosts to which the particular service is
unavailable. Its value can be specified in the same way as the value of
the only_from attribute. These two attributes determine the location
access control enforced by xinetd. If none of the two is specified for a
service, the service is available to anyone. If both are specified for a
service, the one that is the better match for the address of the remote
host determines if the service is available to that host (for example, if
the only_from list contains 128.138.209.0 and the no_access list contains
128.138.209.10 then the host with the address 128.138.209.10 can not
access the service).
access_times determines the time intervals when the service is available. An interval
has the form hour:min-hour:min (connections will be accepted at the
bounds of an interval). Hours can range from 0 to 23 and minutes from 0
to 59.
log_type determines where the service log output is sent. Select just one of the
two formats:
SYSLOG syslog_facility [syslog_level]
The log output is sent to syslog at the specified facility.
Possible facility names include: daemon, auth, authpriv, user,
mail, lpr, news, uucp, ftp local0-7. Possible level names
include: emerg, alert, crit, err, warning, notice, info, debug.
If a level is not present, the messages will be recorded at the
info level.
FILE file [soft_limit [hard_limit]]
The log output is appended to file which will be created if it
does not exist. Two limits on the size of the log file can be
optionally specified. The first limit is a soft one; xinetd will
log a message the first time this limit is exceeded (if xinetd
logs to syslog, the message will be sent at the alert priority
level). The second limit is a hard limit; xinetd will stop
logging for the affected service (if the log file is a common log
file, then more than one service may be affected) and will log a
message about this (if xinetd logs to syslog, the message will be
sent at the alert priority level). If a hard limit is not
specified, it defaults to the soft limit increased by 1% but the
extra size must be within the parameters LOG_EXTRA_MIN and
LOG_EXTRA_MAX which default to 5K and 20K respectively (these
constants are defined in xconfig.h).
log_on_success determines what information is logged when a server is started and when
that server exits (the service id is always included in the log entry).
Any combination of the following values may be specified:
PID logs the server process id (if the service is implemented by
xinetd without forking another process the logged process id
will be 0)
HOST logs the remote host address
USERID logs the user id of the remote user using the RFC 1413
identification protocol. This option is available only for
multi-threaded stream services.
EXIT logs the fact that a server exited along with the exit status
or the termination signal (the process id is also logged if
the PID option is used)
DURATION logs the duration of a service session
TRAFFIC logs the total bytes in and out for a redirected service.
log_on_failure determines what information is logged when a server cannot be started
(either because of a lack of resources or because of access control
restrictions). The service id is always included in the log entry along
with the reason for failure. Any combination of the following values may
be specified:
HOST logs the remote host address.
USERID logs the user id of the remote user using the RFC 1413
identification protocol. This option is available only for
multi-threaded stream services.
ATTEMPT logs the fact that a failed attempt was made (this option is
implied by all others).
rpc_version determines the RPC version for a RPC service. The version can be a single
number or a range in the form number-number.
rpc_number determines the number for an UNLISTED RPC service (this attribute is
ignored if the service is not unlisted).
env The value of this attribute is a list of strings of the form
'name=value'. These strings will be added to the environment before
starting a server (therefore the server's environment will include
xinetd's environment plus the specified strings).
passenv The value of this attribute is a list of environment variables from
xinetd's environment that will be passed to the server. An empty list
implies passing no variables to the server except for those explicitly
defined using the env attribute. (notice that you can use this attribute
in conjunction with the env attribute to specify exactly what environment
will be passed to the server).
port determines the service port. If this attribute is specified for a service
listed in /etc/services, it must be equal to the port number listed in
that file.
redirect Allows a tcp service to be redirected to another host. When xinetd
receives a tcp connection on this port it spawns a process that
establishes a connection to the host and port number specified, and
forwards all data between the two hosts. This option is useful when your
internal machines are not visible to the outside world. Syntax is:
redirect = (ip address) (port). You can also use a hostname instead of
the IP address in this field. The hostname lookup is performed only
once, when xinetd is started, and the first IP address returned is the
one that is used until xinetd is restarted. The "server" attribute is
not required when this option is specified. If the "server" attribute is
specified, this attribute takes priority.
bind Allows a service to be bound to a specific interface on the machine.
This means you can have a telnet server listening on a local, secured
interface, and not on the external interface. Or one port on one
interface can do something, while the same port on a different interface
can do something completely different. Syntax: bind = (ip address of
interface).
interface Synonym for bind.
banner Takes the name of a file to be splatted at the remote host when a
connection to that service is established. This banner is printed
regardless of access control. It should *always* be printed when a
connection has been made. xinetd outputs the file as-is, so you must
ensure the file is correctly formatted for the service's protocol. In
particular, if the protocol requires CR-LF pairs for line termination,
you must supply them.
banner_success Takes the name of a file to be splatted at the remote host when a
connection to that service is granted. This banner is printed as soon as
access is granted for the service. xinetd outputs the file as-is, so you
must ensure the file is correctly formatted for the service's protocol.
In particular, if the protocol requires CR-LF pairs for line termination,
you must supply them.
banner_fail Takes the name of a file to be splatted at the remote host when a
connection to that service is denied. This banner is printed immediately
upon denial of access. This is useful for informing your users that they
are doing something bad and they shouldn't be doing it anymore. xinetd
outputs the file as-is, so you must ensure the file is correctly
formatted for the service's protocol. In particular, if the protocol
requires CR-LF pairs for line termination, you must supply them.
per_source Takes an integer or "UNLIMITED" as an argument. This specifies the
maximum instances of this service per source IP address. This can also
be specified in the defaults section.
cps Limits the rate of incoming connections. Takes two arguments. The first
argument is the number of connections per second to handle. If the rate
of incoming connections is higher than this, the service will be
temporarily disabled. The second argument is the number of seconds to
wait before re-enabling the service after it has been disabled. The
default for this setting is 50 incoming connections and the interval is
10 seconds.
max_load Takes a floating point value as the load at which the service will stop
accepting connections. For example: 2 or 2.5. The service will stop
accepting connections at this load. This is the one minute load average.
This is an OS dependent feature, and currently only Linux, Solaris, and
FreeBSD are supported for this. This feature is only available if xinetd
was configured with the -with-loadavg option.
groups Takes either "yes" or "no". If the groups attribute is set to "yes",
then the server is executed with access to the groups that the server's
effective UID has access to. Alternatively, if the group attribute is
set, the server is executed with access to the groups specified. If the
groups attribute is set to "no", then the server runs with no
supplementary groups. This attribute must be set to "yes" for many BSD
systems. This attribute can be set in the defaults section as well.
mdns Takes either "yes" or "no". On systems that support mdns registration of
services (currently only Mac OS X), this will enable or disable
registration of the service. This defaults to "yes".
umask Sets the inherited umask for the service. Expects an octal value. This
option may be set in the "defaults" section to set a umask for all
services. xinetd sets its own umask to the previous umask OR'd with 022.
This is the umask that will be inherited by all child processes if the
umask option is not used.
enabled Takes a list of service ID's to enable. This will enable only the
services listed as arguments to this attribute; the rest will be
disabled. If you have 2 ftp services, you will need to list both of
their ID's and not just ftp. (ftp is the service name, not the ID. It
might accidentally be the ID, but you better check.) Note that the
service "disable" attribute can prevent a service from being enabled
despite being listed in this attribute.
include Takes a filename in the form of "include /etc/xinetd/service". The file
is then parsed as a new configuration file. It is not the same thing as
pasting the file into xinetd.conf where the include directive is given.
The included file must be in the same form as xinetd.conf. This may not
be specified from within a service. It must be specified outside a
service declaration.
includedir Takes a directory name in the form of "includedir /etc/xinetd.d". Every
file inside that directory, excluding files with names containing a dot
('.') or ending with a tilde ('~'), will be parsed as xinetd
configuration files. The files will be parsed in alphabetical order
according to the C locale. This allows you to specify services one per
file within a directory. The includedir directive may not be specified
from within a service declaration.
rlimit_as Sets the Address Space resource limit for the service. One parameter is
required, which is either a positive integer representing the number of
bytes to set the limit to (K or M may be used to specify
kilobytes/megabytes) or "UNLIMITED". Due to the way Linux's libc malloc
is implemented, it is more useful to set this limit than rlimit_data,
rlimit_rss and rlimit_stack. This resource limit is only implemented on
Linux systems.
rlimit_files Sets the maximum number of open files that the service may use. One
parameter is required, which is a positive integer representing the
number of open file descriptors. Practical limit of this number is around
1024000.
rlimit_cpu Sets the maximum number of CPU seconds that the service may use. One
parameter is required, which is either a positive integer representing
the number of CPU seconds limit to, or "UNLIMITED".
rlimit_data Sets the maximum data size resource limit for the service. One parameter
is required, which is either a positive integer representing the number
of bytes or "UNLIMITED".
rlimit_rss Sets the maximum resident set size limit for the service. Setting this
value low will make the process a likely candidate for swapping out to
disk when memory is low. One parameter is required, which is either a
positive integer representing the number of bytes or "UNLIMITED".
rlimit_stack Set the maximum stack size limit for the service. One parameter is
required, which is either a positive integer representing the number of
bytes or "UNLIMITED".
deny_time Sets the time span that access to all services on all IP addresses are
denied to someone that sets off the SENSOR. The unit of time is in
minutes. Valid options are: FOREVER, NEVER, and a numeric value. FOREVER
causes the IP address not to be purged until xinetd is restarted. NEVER
has the effect of just logging the offending IP address. A typical time
value would be 60 minutes. This should stop most DOS attacks while
allowing IP addresses that come from a pool to be recycled for legitimate
purposes. This option must be used in conjunction with the SENSOR flag.
You don't need to specify all of the above attributes for each service. The necessary
attributes for a service are:
socket_type
user (non-internal services only)
server (non-internal services only)
wait
protocol (RPC and unlisted services only)
rpc_version (RPC services only)
rpc_number (unlisted RPC services only)
port (unlisted non-RPC services only)
The following attributes support all assignment operators:
only_from
no_access
log_on_success
log_on_failure
passenv
env (does not support the '-=' operator)
These attributes can also appear more than once in a service entry. The remaining
attributes support only the '=' operator and can appear at most once in a service entry.
The configuration file may also contain a single defaults entry that has the form
defaults
{
<attribute> = <value> <value> ...
...
}
This entry provides default attribute values for service entries that don't specify those
attributes. Possible default attributes:
log_type (cumulative effect)
bind
per_source
umask
log_on_success (cumulative effect)
log_on_failure (cumulative effect)
only_from (cumulative effect)
no_access (cumulative effect)
passenv (cumulative effect)
instances
disabled (cumulative effect)
enabled (cumulative effect)
banner
banner_success
banner_fail
per_source
groups
cps
max_load
Attributes with a cumulative effect can be specified multiple times
with the values specified each time accumulating (i.e. '=' does the same thing as
'+='). With the exception of disabled they all have the same meaning as if they
were specified in a service entry. disabled determines services that are disabled
even if they have entries in the configuration file. This allows for quick
reconfiguration by specifying disabled services with the disabled attribute instead
of commenting them out. The value of this attribute is a list of space separated
service ids. enabled has the same properties as disabled. The difference being
that enabled is a list of which services are to be enabled. If enabled is
specified, only the services specified are available. If enabled is not specified,
all services are assumed to be enabled, except those listed in disabled.
INTERNAL SERVICES
xinetd provides the following services internally (both stream and datagram based): echo,
time, daytime, chargen, and discard. These services are under the same access
restrictions as all other services except for the ones that don't require xinetd to fork
another process for them. Those ones (time, daytime, and the datagram-based echo, chargen,
and discard) have no limitation in the number of instances.
TCPMUX Services
xinetd supports TCPMUX services that conform to RFC 1078. These services may not have a
well-known port associated with them, and can be accessed via the TCPMUX well-known port.
For each service that is to be accessed via TCPMUX, a service entry in /etc/xinetd.conf or
in a configuration file in an includedir directory must exist.
The service_name field (as defined above for each service in any xinetd configuration
file) must be identical to the string that is passed (according to RFC 1078 protocol) to
xinetd when the remote service requestor first makes the connection on the TCPMUX
well-known port. Private protocols should use a service name that has a high probability
of being unique. One way is to prepend the service name with some form of organization ID.
The type field can be either TCPMUX or TCPMUXPLUS. If the type is TCPMUXPLUS, xinetd will
handle the initial protocol handshake (as defined in RFC 1078) with the calling process
before initiating the service. If the type is TCPMUX, the server that is started is
responsible for performing the handshake.
The type field should also include UNLISTED if the service is not listed in a standard
system file (like /etc/rpc for RPC services, or /etc/services for non-RPC services).
The socket_type for these services must be stream, and the protocol must be tcp.
Following is a sample TCPMUX service configuration:
service myorg_server
{
disable = no
type = TCPMUX
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/my_server_exec
}
Besides a service entry for each service that can be accessed via the TCPMUX well-known
port, a service entry for TCPMUX itself must also be included in the xinetd configuration.
Consider the following sample:
service tcpmux
{
type = INTERNAL
id = tcpmux
socket_type = stream
protocol = tcp
user = root
wait = no
}
NOTES
1. The following service attributes cannot be changed on reconfiguration: socket_type,
wait, protocol, type.
2. When the attributes only_from and no_access are not specified for a service (either
directly or via defaults) the address check is considered successful (i.e. access
will not be denied).
3. The maximum line length of the configuration file is limited to 16 KiB (it might be
less on systems without mmap, the length limit is two times the optimal I/O
blocksize then).
4. The address check is based on the IP address of the remote host and not on its
domain address. We do this so that we can avoid remote name lookups which may take a
long time (since xinetd is single-threaded, a name lookup will prevent the daemon
from accepting any other requests until the lookup is resolved). The down side of
this scheme is that if the IP address of a remote host changes, then access to that
host may be denied until xinetd is reconfigured. Whether access is actually denied
or not will depend on whether the new host IP address is among those allowed access.
For example, if the IP address of a host changes from 1.2.3.4 to 1.2.3.5 and
only_from is specified as 1.2.3.0 then access will not be denied.
5. If the USERID log option is specified and the remote host either does not run an
identification server or the server sends back a bad reply, access will not be
denied unless the IDONLY service flag is used.
6. Interception works by forking a process which acts as a filter between the remote
host(s) and the local server. This obviously has a performance impact so it is up
to you to make the compromise between security and performance for each service.
The following tables show the overhead of interception. The first table shows the
time overhead-per-datagram for a UDP-based service using various datagram sizes.
For TCP-based services we measured the bandwidth reduction because of interception
while sending a certain amount of data from client to server (the time overhead
should the same as for UDP-based services but it is "paid" only by the first packet
of a continuous data transmission). The amount of data is given in the table as
system_callsxdata_sent_per_call, i.e. each send(2) system call transferred so many
bytes of data. The bandwidth reduction is given in terms of bytes per second and as
a percentage of the bandwidth when interception is not performed. All measurements
were done on a SparcStation IPC running SunOS 4.1.
Datagram size (bytes) Latency (msec)
--------------------- --------------
64 1.19
256 1.51
1024 1.51
4096 3.58
Bytes sent Bandwidth reduction
---------- -------------------
10000x64 941 (1.2%)
10000x256 4,231 (1.8%)
10000x1024 319,300 (39.5%)
10000x4096 824,461 (62.1%)
EXAMPLE
#
# Sample configuration file for xinetd
#
defaults
{
log_type = FILE /var/log/servicelog
log_on_success = PID
log_on_failure = HOST
only_from = 128.138.193.0 128.138.204.0
only_from = 128.138.252.1
instances = 10
disabled = rstatd
}
#
# Note 1: the protocol attribute is not required
# Note 2: the instances attribute overrides the default
#
service login
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/in.rlogind
instances = UNLIMITED
}
#
# Note 1: the instances attribute overrides the default
# Note 2: the log_on_success flags are augmented
#
service shell
{
socket_type = stream
wait = no
user = root
instances = UNLIMITED
server = /usr/sbin/in.rshd
log_on_success += HOST
}
service ftp
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/sbin/in.ftpd
server_args = -l
instances = 4
log_on_success += DURATION HOST USERID
access_times = 2:00-9:00 12:00-24:00
}
# Limit telnet sessions to 8 Mbytes of memory and a total
# 20 CPU seconds for child processes.
service telnet
{
socket_type = stream
wait = no
nice = 10
user = root
server = /usr/sbin/in.telnetd
rlimit_as = 8M
rlimit_cpu = 20
}
#
# This entry and the next one specify internal services. Since
# this is the same service using a different socket type, the
# id attribute is used to uniquely identify each entry
#
service echo
{
id = echo-stream
type = INTERNAL
socket_type = stream
user = root
wait = no
}
service echo
{
id = echo-dgram
type = INTERNAL
socket_type = dgram
user = root
wait = no
}
#
# Sample RPC service
#
service rstatd
{
type = RPC
socket_type = dgram
protocol = udp
server = /usr/sbin/rpc.rstatd
wait = yes
user = root
rpc_version = 2-4
env = LD_LIBRARY_PATH=/etc/securelib
}
#
# Sample unlisted service
#
service unlisted
{
type = UNLISTED
socket_type = stream
protocol = tcp
wait = no
server = /home/user/some_server
port = 20020
}
SEE ALSO
xinetd(1L),
xinetd.log(5)
Postel J., Echo Protocol, RFC 862, May 1983
Postel J., Discard Protocol, RFC 863, May 1983
Postel J., Character Generator Protocol, RFC 864, May 1983
Postel J., Daytime Protocol, RFC 867, May 1983
Postel J., Harrenstien K., Time Protocol, RFC 868, May 1983
M. Lottor, TCP Port Service Multiplexer (TCPMUX), RFC 1078 Nov 1988
StJohns M., Identification Protocol, RFC 1413, February 1993
BUGS
If the INTERCEPT flag is not used, access control on the address of the remote host is not
performed when wait is yes and socket_type is stream.
The NOLIBWRAP flag is automatically turned on for RPC services whose socket_type is stream
because xinetd cannot determine the address of the remote host.
If the INTERCEPT flag is not used, access control on the address of the remote host for
services where wait is yes and socket_type is dgram is performed only on the first packet.
The server may then accept packets from hosts not in the access control list. This can
happen with RPC services.
There is no way to put a SPACE in an environment variable.
When wait is yes and socket_type is stream, the socket passed to the server can only
accept connections.
The INTERCEPT flag is not supported for internal services or multi-threaded services.
14 June 2001 XINETD.CONF(5)