XINETD.CONF(5L)

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.

    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:

    REUSE
        Set the SO_REUSEADDR flag on the service socket (check setsockopt(2) for more information).

    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.

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.

interface
    This attribute specifies the IP address or hostname the service will be bind to. You may use a numerical adress, a specific hostname with a valid DNS entry or '0' (INADDR_ANY) for any host.

wait
    This attribute determines if the service is single-threaded or multi-threaded. 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. If the attribute value is no, the service is multi-threaded and xinetd will keep handling new service requests.

user
    determines the uid for the server process. 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 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.

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.

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.

    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.

    c)  a network name (from /etc/networks)

    d)  a host name. All IP addresses of the specified host name will be used.

    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. There are two formats:

    SYSLOG  syslog_facility [syslog_level]
        The log output is sent to syslog at the specified facility. Possible facility names include: daemon, auth, user, 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 config.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

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).

    RECORD
        records information from the remote end in case the server could not be started. This allows monitoring of attempts to use the service. For example, the login service logs the local user, remote user and terminal type. Currently, the services that support this option are: login, shell, exec, finger.

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 conjuction with the env attribute to specify exactly what argument 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.

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-unlisted 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

    log_on_success
        (cumulative effect)

    log_on_failure
        (cumulative effect)

    only_from
        (cumulative effect)

    no_access
        (cumulative effect)

    passenv
        (cumulative effect)

    instances

    interface

    disabled
        (cumulative effect)

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.

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.

xinetd also provides two UNLISTED internal stream-based services: servers and services. The former lists information about running servers while the latter provides a list of currently active services. There is one service per line and each line contains the service name, protocol (e.g. "tcp") and port number.

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 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.

4.  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.

5.  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 RECORD

        only_from
            = 128.138.193.0 128.138.204.0 128.138.209.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/etc/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/etc/in.rshd

        log_on_success
            += HOST RECORD
    }
    service ftp
    {

        socket_type
            = stream

        wait
            = no

        nice
            = 10

        user
            = root

        server
            = /usr/etc/in.ftpd

        server_args
            = -l

        instances
            = 4

        log_on_success
            += DURATION HOST USERID

        access_times
            = 2:00-9:00 12:00-24:00
    }
    #
    # 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
    }
    service servers
    {

        type
            = INTERNAL UNLISTED

        protocol
            = tcp

        port
            = 9099

        socket_type
            = stream

        wait
            = no
    }
    #
    # Sample RPC service
    #
    service rstatd
    {

        type
            = RPC

        socket_type
            = dgram

        protocol
            = udp

        server
            = /usr/etc/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

StJohns M., Identification Protocol , RFC 1413, February 1993

BUGS

Supplementary group ids are not supported.

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.

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.