xinetd.conf(inc) - phpMan

XINETD.CONF(5)                File Formats Manual               XINETD.CONF(5)

NAME
       xinetd.conf - Extended Internet Services Daemon configuration file
DESCRIPTION
       xinetd.conf is the configuration file that determines the services pro-
       vided 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  fol-
       lowing 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 stan-
                                    dard 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 inter-
                                    cepted).
                        NORETRY     Avoid retry attempts in case of fork fail-
                                    ure.
                        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  con-
                                    nection-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.  This  flag  has  to  be  specified
                                    before  "server_args",  otherwise  is  not
                                    taken into account.
                        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 tcp-
                                    wrap 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 con-
                                    text to match that of the incoming connec-
                                    tion  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  ser-
                                    vices now implicitly use the REUSE flag.
       disable          This  is  boolean  "yes" or "no".  This will result in
                        the service being disabled and not starting.  See  the
                        DISABLE flag description.
       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  ser-
                        vice.   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 simulta-
                        neously 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 (possi-
                        bly negative) number; check nice(3) for more  informa-
                        tion.
       server           determines the program to execute for this service.
       server_args      determines the arguments passed to the server. In con-
                        trast to inetd, the server name should not be included
                        in server_args.
       +.B 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 ser-
                        vices and the service name for  redirected  services).
                        This  attribute  is only valid if xinetd has been con-
                        figured 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 speci-
                             fied 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. There
                        are two formats:
                        SYSLOG  syslog_facility [syslog_level]
                               The log output is sent to syslog at the  speci-
                               fied 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 ser-
                               vice (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  oth-
                                    ers).
       rpc_version      determines the RPC version for a RPC service. The ver-
                        sion 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  envi-
                        ronment 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  dif-
                        ferent.  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  ser-
                        vice's   protocol.   In  paticular,  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 paticular, 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 paticular, 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 con-
                        nections per second to handle.  If the rate of  incom-
                        ing  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 ser-
                        vice 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 avaliable if xinetd  was  config-
                        ured 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  and
                        "DISABLE"  flag  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 speci-
                        fied 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  kilo-
                        bytes/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  posi-
                        tive  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 ser-
                        vice 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 ser-
                        vice.   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 ser-
                        vice.  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  "UNLIM-
                        ITED".
       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 mul-
              tiple 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 ser-
       vices  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, char-
       gen, and discard) have no limitation in the number of instances.
TCPMUX Services
       xinetd supports TCPMUX services that conform to RFC  1078.  These  ser-
       vices  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  TCP-
       MUXPLUS,  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 per-
       forming 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/etc/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 reconfigura-
           tion: 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 con-
           sidered 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  reconfig-
           ured.   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 vari-
           ous datagram sizes.  For TCP-based services we measured  the  band-
           width  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  band-
           width reduction is given in terms of bytes per second and as a per-
           centage 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/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
              }
              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
              }
              # 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/etc/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/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
       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)