hosts_options(5)hosts_options(5)NAMEhosts_options - host access control language extensions
This manual page describes the optional extensions to the language
described in hosts_access(5).
The extensible language uses the following format:
The first two fields are described in hosts_access(5). Briefly, dae‐
mon_list is a list of one or more daemon process names or wildcards.
client_list is a list of one or more host names, host addresses, pat‐
terns or wildcards that will be matched against the client host name or
The remainder of the rules is a list of zero or more options. Any ":"
characters within options must be protected with a backslash "\".
An option is of the form "keyword" or "keyword value". Options are
processed in the specified order. Some options are subjected to sub‐
stitutions. For the sake of backwards compatibility with earlier ver‐
sions, an equals sign "=" is permitted between keyword and value.
Change the severity level at which the event will be logged. Facility
names (such as mail) are optional and are not supported on systems with
older implementations. See syslog(3C) related to facilities. The
severity option can be used to emphasize or to ignore specific events.
Access Control Options
Grant or deny the service for and options respectively. These options
must appear at the end of a rule.
The and keywords make it possible to keep all access control rules
within a single file, for example in the file. Examples are as fol‐
To permit access from specific hosts only:
To permit access from all hosts except a few trouble-makers:
Notice the leading dot (.) on the domain name patterns.
Running Other Commands
Execute, in a child process, the specified shell command, after
performing the expansions described in hosts_access(5). The
command is executed with and connected to the null device, so
that it will not mess up the conversation with the client host.
executes, in a background child process, the shell command
after replacing by the name or address of the remote host.
The example uses the command instead of the regular command to
limit possible damage from data sent by the finger server. The
command is part of the daemon wrapper package. It is a wrapper
around the regular command that filters the data sent by the
Replace the current process by an instance of the specified shell
command, after performing the expansions described in
hosts_access(5). and are connected to the client process. This
option must appear at the end of a rule.
To send a customized bounce message to the client instead of
running the real ftp daemon:
For an alternative way to communicate with the client processes,
see the option below.
To run /some/other/telnetd without polluting its command-line
array or its process environment:
WARNING: in case of UDP services, do not twist to commands that use
the standard I/O or the routines to communicate with the client
process. UDP requires other I/O primitives.
Causes the server to periodically send a message to the client. The
connection is considered broken when the client does not
respond. The option can be useful when users turn off their
machine while it is still connected to a server. The option is
not useful for datagram (UDP) services.
Specifies how long the kernel will try to deliver undelivered
data after the server process closes a connection.
Username Lookup Options
Look up the client user name with the RFC 931 (TAP, IDENT, RFC 1413)
protocol. This option is silently ignored in case of services
based on transports other than TCP. It requires that the client
system runs an RFC 931-compliant daemon (IDENT etc.) and may
cause noticeable delays with connections from non-UNIX clients.
The timeout period is tunable through configuration file If no
or invalid timeout is specified, the user name lookup is dis‐
Look for a file in
/some/directory with the same name as the daemon process (for
example, for the telnet service), and copy its contents to the
client. Newline characters are replaced by carriage-return new‐
line, and sequences are expanded (see hosts_access(5)).
The banner option does not add any service-specific characters
when sending the text to the client as specified in the service
protocol. To use this option successfully, the file must con‐
tain the necessary protocol parameters in addition to the actual
For example, in an service, the lines in the banners file are
not automatically prefixed by the status code as defined in FTP
RFC 959. Therefore, if you want to send the following text to
the FTP client:
This is a sample Welcome text to demonstrate the banners
option in tcpd.
we recommend adding the protocol-specific response code as fol‐
220-This is a sample Welcome text to demonstrate the banners
220-option in tcpd.
For the service, a null character must be placed at the begin‐
ning of the banner file as specified in the following example:
# echo "\0This is a sample Welcome text to demonstrate \
the banners" > rlogind
# echo "option in tcpd." >> rlogind
The file may be used to generate banners for multiple services.
For more information, refer to
WARNING: Banners are supported for connection-oriented (TCP)
network services only.
Change the nice value of the process (default 10). Specify a positive
value to spend more CPU resources on other processes.
Place a (name, value) pair into the process environment. The value is
subjected to expansions and may contain whitespace (but leading
and trailing blanks are stripped off).
WARNING: Many network daemons reset their environment before
spawning a login or shell process.
command that is built into the shell. A of 022 prevents the
creation of files with group and world write permission. The
argument must be an octal number.
Assume the privileges of the "someuser" userid (or user "someuser",
"somegroup"). The first form is useful with implementations
that run all services with root privilege. The second form is
useful for services that need special group privileges only.
Problems are reported via the daemon, at and levels. When a syntax
error is found in an access control rule, the error is reported to the
daemon; further options will be ignored, and service is denied.
Wietse Venema (firstname.lastname@example.org)
Department of Mathematics and Computing Science
Eindhoven University of Technology
Den Dolech 2, P.O. Box 513,
5600 MB Eindhoven, The Netherlands
SEE ALSOhosts_access(5), the default access control language.