There is a built-in precedence to the WrapUserTables, WrapGroupTables, and WrapTables directives, if all are used. mod_wrap2 will look for applicable WrapUserTables for the connecting user first. If no applicable WrapUserTables are found, mod_wrap2 will search for WrapGroupTables which pertain to the connecting user. If not found, mod_wrap2 will then look for the server-wide WrapTables directive. This allows for access control to be set on a per-server basis, and allow for per-user or per-group access control to be handled without interfering with the overall server access rules.

When checking the tables, mod_wrap2 always checks the allow table first. If the client has been explicitly allowed by the rules in that table, processing stops and mod_wrap2 allows the client to continue the session. If not explicitly allowed, mod_wrap2 will then check the deny table's access rules. If the client has been explicity denied by rules in that table, mod_wrap2 will disconnect the client. By default, if neither explicitly allowed or explicitly denied, mod_wrap2 will allow the client to continue.

In addition to the various formats supported by the submodules, there is a special source type: "builtin". This is used in the situations where the administrator wishes to configure "mostly closed" access rules, the most common situation. For example, if all clients are to be denied by mod_wrap2 by default, unless that client is granted access via an allow table entry, then the administrator can use:

  builtin:all

Access Rules

Patterns
The access control language implements the following patterns:

• A string that begins with a `.' character. A host name is matched if the last components of its name match the specified pattern. For example, the pattern .castaglia.org matches the host name golem.devlan.castaglia.org.

• A string that ends with a `.' character. A host address is matched if its first numeric 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).

• A string that begins with an `@' character is treated as an NIS (formerly YP) netgroup name. A host name is matched if it is a host member of the specified netgroup. Netgroup matches are not supported for client user names. Note that mod_wrap2 must be configured for NIS support for netgroup lookups to occur.

• An expression of the form n.n.n.n/m.m.m.m is interpreted as a net/mask pair. An IPv4 address is matched if the net portion is equal to the bitwise AND of the address and the mask portion. 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 `*' and `?' can be used to match hostnames or IP addresses. This method of matching cannot be used in conjunction with net/mask matching, hostname matching beginning with `.' or IP address matching ending with `.'.

Wildcards
The access control language supports explicit wildcards:

• ALL
  The universal wildcard, always matches.

• LOCAL
  Matches any host whose name does not contain a dot character.

• UNKNOWN
  Matches any user whose name is unknown, and matches any host whose name or address are unknown. This pattern should be used with care: host names may be unavailable due to temporary name server problems.

• KNOWN
  Matches any user whose name is known, and matches any host whose name and address are known. This pattern should be used with care: host names may be unavailable due to temporary name server problems.

• PARANOID
  Matches any host whose name does not match its address, before looking at the access control tables.

Operators

• EXCEPT
  Intended use is of the form:

    list1 EXCEPT list2
  

  This construct matches anything that matches list1 unless it matches list2. The EXCEPT operator can be used in daemon lists and 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))
  

Server Endpoint Patterns
In order to distinguish clients by the network address that they connect to, use patterns of the form:

  process-name@host-pattern : client-list ...

The host-pattern obeys the same syntax rules as host names and addresses in client lists.

Client Username Lookup
When the client host supports the RFC 931 protocol, the proftpd daemon can retrieve additional information about the owner of a connection. Client username information, when available (i.e. when IdentLookups are not disabled), is logged together with the client host name, and can be used to match patterns like:

  daemon-list : ... user-pattern@host-pattern ...

A user-pattern has the same syntax as a daemon pattern, so the same wildcards apply (netgroup membership is not supported). One should not get carried away with username lookups, though:

• The client username information cannot be trusted when it is needed most, i.e. when the client system has been compromised. In general, ALL and (UN)KNOWN are the only user name patterns that make sense.

• Username lookups are possible only when the client host runs a suitable daemon; in all other cases the result is "unknown".

Access Options

  opt1 : opt2 ...

An option is of the form "keyword" or "keyword value". Options are processed in the specified order. For the sake of backwards compatibility with earlier versions, a `=' is permitted between keyword and value.

• ALLOW
  Grant service. This option must appear at the end of a rule.
• DENY
  Deny service. This option must appear at the end of a rule.

The allow and deny keywords make it possible to keep all access control rules within a single file, for example in the hosts.allow file. To permit access from specific hosts only:

    ALL: .friendly.domain: ALLOW
    ALL: ALL: DENY

    ALL: .bad.domain: DENY
    ALL: ALL: ALLOW

• nice [number]
  Change the nice value of the process (default 10). Specify a positive value to spend more CPU resources on other processes.

• setenv name=value
  Place a name=value pair into the process environment. The value may contain whitespace (but leading and trailing blanks are stripped off).

Diagnostics
When a syntax error is found in an options list, the error is reported in the WrapLog and the access option will be ignored.

Installation

  ./configure --with-modules=wrap-modules
  make
  make install

For file-based access tables, include the mod_wrap2_file submodule, e.g.:

  mod_wrap2:mod_wrap2_file

  mod_wrap2:mod_wrap2_sql

  mod_wrap2:mod_wrap2_file:mod_wrap2_sql