CGI Security Documentation

CGIWrap Access Control Files

CGIWrap access control files provide a structured way to allow or deny CGI script execution based on user identity, host rules, and virtual host configuration. For Unix administrators managing shared environments, these controls add another layer of protection around CGI security and execution policy.

How CGIWrap Access Control Works

CGIWrap includes an access control mechanism that works similarly to traditional allow and deny logic used in other Unix administrative tools. It is intended to help administrators limit who can execute scripts through CGIWrap, which can be especially useful in cases involving abuse, excessive CPU usage, or obvious security concerns. This feature is not always required in every setup, but it can become very valuable when tighter CGI script restrictions are needed.

Access control support is only effective when it has been enabled during CGIWrap configuration and installation. If that option is not compiled into the software, the allow and deny files described here will have no effect. That makes installation-time planning important for anyone who wants to use CGIWrap as part of a more controlled Unix web server security strategy.

Access Control Logic

  • Neither file exists: configuration error.
  • User appears in both files: access denied.
  • Allow file exists and user is not listed: access denied.
  • Deny file exists and user is listed: access denied.
  • Otherwise: access allowed.

In practical terms, CGIWrap requires a user to appear in the allow file when that file exists, and the user must not appear in the deny file when a deny file is present. This creates a predictable decision path that is straightforward for system administrators to audit and maintain.

File Format

Without host checking enabled, the file format is simple: one user ID per line. This follows the same basic style used by traditional cron allow and deny files, making it familiar to many Unix administrators.

With host checking enabled, the format expands to include both the user and a network definition. The expected pattern is:

userid@xxx.xxx.xxx.xxx/yyy.yyy.yyy.yyy

In this structure, the x values represent the network and the y values represent the subnet mask. The user ID may also be entered as * to match all users for a given network and mask combination. This makes host-based filtering more flexible when you need broader policy enforcement across a range of addresses.

VHost Access Control

If the virtual host access control option is enabled, CGIWrap will also check a per-vhost access control file before allowing execution. These files are stored in the vhost-allow-dir and vhost-deny-dir locations defined at configure time, and their names are based on the lowercase value of HTTP_HOST.

When both global access control and virtual host access control are enabled, CGIWrap checks both layers. That means administrators can apply broad system-wide policies while also enforcing more specific rules at the individual virtual host level. For multi-site Unix hosting environments, this adds useful control without requiring entirely separate access systems.