Page 1133
HISTORY
Written by Rich $alz (rsalz@uunet.uu.net) for InterNetNews.
SEE ALSO
ctlinnd(8), innd(8), nnrpd(8)
hosts_access—Format of host access control files.
DESCRIPTION
This manual page describes a simple access control language that is based on client (hostname/address, username) and server (process name) patterns. Examples are given at the end. The impatient reader can skip to the "Examples" section for a quick introduction.
In the following text, daemon is the process name of a network daemon process, and client is the name or address of a host requesting service. Network daemon process names are specified in the inetd configuration file.
ACCESS CONTROL FILES
The access control software consults two files. The search stops at the first match:
Access will be granted when a (daemon,client) pair matches an entry in the /etc/hosts.allow file.
Otherwise, access will be denied when a (daemon,client) pair matches an entry in the /etc/hosts.deny file.
Otherwise, access will be granted.
A non-existing access control file is treated as if it were an empty file. Thus, access control can be turned off by providing no access control files.
ACCESS CONTROL RULES
Each access control file consists of zero or more lines of text. These lines are processed in order of appearance. The search terminates when a match is found.
A newline character is ignored when it is preceded by a backslash character.
Blank lines or lines that begin with a # character are ignored.
All other lines should satisfy the following format, things between [] being optional:
daemon_list : client_list [ : shell_command ]
daemon_list is a list of one or more daemon process names (argv[0] values) or wildcards.
client_list is a list of one or more hostnames, host addresses, patterns, or wildcards that will be matched against the remote hostname or address.
List elements should be separated by blanks or commas.
With the exception of NIS (YP) netgroup lookups, all access control checks are case insensitive.
PATTERNS
The access control language implements the following patterns:
A string that begins with a . character: A client name or address is matched if its last components match the specified pattern. For example, the pattern .tue.nl matches the hostname wzv.win.tue.nl.
A string that ends with a . character: A client name or address is matched if its first fields match the given string. For example, the pattern 131.155. matches the address of (almost) every host on the Eindhoven University network (131.155.x.x).
Page 1134
A string that begins with a @ character is treated as a netgroup name: Netgroups are usually supported on systems with NIS (formerly YP) databases. A client hostname is matched if it is a (host) member of the specified netgroup.
An expression of the form n.n.n.n/m.m.m.m is interpreted as a net/mask pair. A client address is matched if net is equal to the bitwise AND of the address and the mask. For example, the net/mask pattern 131.155.72.0/255.255.254.0 matches every address in the range 131.155.72.0 through 131.155.73.255.
WILDCARDS
The access control language supports explicit wildcards:
| ALL | If this token appears in a daemon list, it matches all network daemon process names. If the ALL token appears in a client list, it matches all client names and addresses. |
| LOCAL | Matches any string that does not contain a dot character. Typical use is in client lists. |
| UNKNOWN | Matches any host whose name or address are unknown. Should be used with care: Hostnames may be unavailable due to temporary nameserver problems. A network address will be unavailable when the software cannot figure out what type of network it is talking to. |
| KNOWN | Matches any host whose name and address are known. Should be used with care: Hostnames may be unavailable due to temporary nameserver problems. A network address will be unavailable when the software cannot figure out what type of network it is talking to. |
| FAIL | Like the ALL wildcard but causes the software to pretend that the scan of the current access control table fails. FAIL is being phased out; it will become an undocumented feature. The EXCEPT operator is a much cleaner alternative. |
OPERATORS
| EXCEPT |
Intended use is of the form: list_1 EXCEPT list_2; this construct matches anything that matches
list_1 unless it matches list_2. This construct can be used in daemon lists and in client lists. The EXCEPT operator can be nested: If the control language would permit the use of parentheses, a EXCEPT b EXCEPT c would parse as (a EXCEPT (b EXCEPT c)). |
SHELL COMMANDS
If the first-matched access control rule contains a shell command, that command is subjected to the following substitutions:
| %a | Expands to the remote host address. |
| %c | Expands to client information: user@host, user@address, a hostname, or just an address, depending on how much information is available. |
| %h | Expands to the remote hostname (or address, if the hostname is unavailable). |
| %d | Expands to the daemon process name (argv[0] value). |
| %p | Expands to the daemon process ID. |
| %u | Expands to the remote username (or unknown). |
| %% | Expands to a single % character. |
Characters in % expansions that may confuse the shell are replaced by underscores. The result is executed by a /bin/sh child process with standard input, output, and error connected to /dev/null. Specify an & at the end of the command if you do not want to wait until it has completed.
Shell commands should not rely on the PATH setting of the inetd. Instead, they should use absolute pathnames, or they should begin with an explicit PATH=whatever statement.
REMOTE USERNAME LOOKUP
When the client host supports the RFC 931 protocol or one of its descendants (TAP, IDENT) the wrapper programs can retrieve additional information about the owner of a connection. When available, remote username information is logged together with the client hostname and can be used to match patterns like
daemon_list : ... user_pattern@host_pattern ...