AA Additions to Rule File

Access Authorization brings two additional rules to the rule file: protect and defprot. They have the same syntax:

        defprot <template> <setupfile> <uid.gid>
        protect <template> <setupfile> <uid.gid>

<template>

is the usual template used in rule file to match agaist the requested URL.

<setupfile>

is a pathname for protection setup file which sets up the actual protection parameters.

Setup file can be omitted from protect rule, but it is obligatory in defprot rule. If setup file is omitted it is not possible to give the <uid.gid> part, either.

<uid.gid>

are the Unix user id and group id (either by name or by number, separated by comma) to which the server should change when serving the request. These are only meaningful when the server is running as root.

These can be omitted, when they default to nobody and nogroup. Also either part by itself may be omitted, as far it is kept in mind that the dot belongs to the group id part:

	user.group        user        .group

are all valid.

The defprot Rule

defprot rule specifies the default protection setup file and process uid and gid.

defprot by itself does not protect anything, but if protection is later on turned on by

either an existing access control list file
or a protect rule without setup file name

the protection settings of defprot rule are used. Rule translation continues normally after defprot rule. If another defprot rule is matched it overrides the previous.

The protect Rule

protect rule tells the server, that the document matching template is protected. If protection setup file is not specified it is taken from the previously matched defprot. If no defprot rule has matched before it is an error.

Rule translation continues normally, but the document is served in protected mode: either an access control list file (.www_acl) must be found in the same directory as the document, or a mask must be present in protection setup file, (or both) and in addition, of course, the requirements in mask/ACL must be met (i.e. the user/IP number must belong to an allowed group).

If another protect rule is matched it overrides the privious one.

Note: Even without protect rule protection is enabled if there is an Access Control List in the same directory as the requested file.

The reason for protect rule existing is that it is possible to tell that an entire hierarchy of files is protected, and if for some reason the ACL is missing, it does not result in protected files being exposed.

It can also be used to avoid having ACLs alltogether when Mask-Group is set in the protection setup file.

Examples

    defprot  *               /WWW/httpd.prot
    protect  /priv/*         /WWW/priv/httpd.prot         foo.bar
    protect  /priv/secret/*  /WWW/priv/secret/httpd.prot  foo.bar
    fail     *.prot
    map      /*              file:/WWW/*
    fail     *

This setup uses protection setup files in the top-level directory for each different protection level (this doesn't need to be the case). When accessing "private" and "secret" files the server sets its process user and group id to foo and bar. Otherwise it is running as nobody in nogroup. fail rule explisitly fails every request to access any protection setup files (however, they need not be called

httpd.prot).

AL 12 December 1993