OS/2 Shareware BBS: 35 Internet/35-Internet.zip/srev13h.zip/ADDPRIVS.DOC

Text File | 1999-05-10 | 8KB | 162 lines

15 Apr 1998
       Description of SRE-http's "additional, dynamic" privileges.

The "SEL-specific" access control facility of SRE-http is based on
matching  "client privileges" to the "resource privileges"
list associated with the "request selector".  This document describes
this process, with a focus on the use of "additional, dynamic" privileges.

In short: Privileges  are granted to a client through several
         "static" mechanisms, and a dynamic mechanism.
          These privileges are compared against the "resource
          privileges" list.

A) Static client privileges

Assignation of static client privileges is a multi-step process:
  i)  OWNERS (with IP addresses specified in the OWNERS variable)
      are granted a SUPERUSER privilege.
 ii)  Clients with an IP address that matches (possibly using wildcards)
      an INHOUSEIPS. stem variable are granted an INHOUSE privilege, and
      are granted privileges contained in the matching INHOUSEIPS. entry.
           Actually, they are granted the priviliges listed in the
           INHOUSE_PRIVS variable (by default, INHOUSE_PRIVS="INHOUSE")
 iii) If neither i or ii apply, then USERS.IN file is examined.  USERS.IN
      contains, on a username/password specific basis, a privilege list.
      If this step is required, the client may be sent an authorization
      request (depending on whether an authorization request header
      was recieved).
            Alternatively, a custom USER_LOGON_PROC can be used, which may
            (or may not) use the USERS.IN file.
 iv) Everyone (who is given logon access) is granted the privileges listed
     in the PUBLIC_PRIVS variable.
  v) If ADD_USER_NAME='YES', then the "username" (or first portion of
      an INHOUSEIPS. IP address) is added to the client privilege list.

For a given client, static privileges are always the same. In contrast,
dynamic privileges are granted on a short term basis, perhaps as a function
of transient events.  But before describing dynamic privileges,
a few words on  "resource privileges" are in order.

B) Resource Privileges

Regardless of the source of each of a client's privileges, SEL-specific
access control requires that the resource privileges are satisfied
by the client's privileges.  This "satisfaction" is based on two tests:
    i) Any of the "ONE_OF" resource privileges are satisfied
   ii) All of the "MUST_HAVE" resource privileges are satisfied.
Basically, the ONE_OF resource privileges  are "or" conditions, and
the MUST_HAVE are "and" conditions.  Satisfaction of all the
MUST_HAVE resource privileges is a necessary, but not sufficient,
condition -- at least one of the ONE_OF resource privileges are required.

    Note: if there are no ONE_OF conditions, it is assumed that the
          "ONE_OF conditions are automatically satisfied" (the same can be
          said if there are no MUST_HAVE conditions).

As an aside:
    The "resource privileges" are determined using:
        "SEL-specific" entries, and
        "REALM-specific entries"
   in the ACCESS_FILE (see ACCESS.IN for details).
   In addition:
       If ADD_RESOURCE_NAME='YES', the "action" portion of the
       "request selector" is added,
           (the "action" portion is the part of the request selector before
            the first ? character).
       Thus, a request selector of STARS/RIGEL.HTM would yield a "resource
       privilege" of STARS/RIGEL.HTM.

C) Dynamic Client Privileges

Now, let us consider dynamic privileges. The notion underlying
dynamic privileges is that one might wish to grant conditional
access to server resources, where the condition is a function of
recent history.  For example:
  i) you  want clients to fill out a registration form before giving them
     access to a set of data files, with the registration good for a limited
     time span (say, 30 minutes).
 ii) you wish to enforce a particular order in viewing linked
     documents, with no "skipping ahead".
iii) you have an images archive you're happy to give away, but
     you don't want lazy websters to include links to these images
     in their web pages.

 All these cases can be easily handled through the use of dynamic privileges.

Dynamic privileges are granted by adding entries to a "dynamic privileges"
cache. To use this cache, you first have to make sure that the SRE-http
variable CHECK_ADD_PRIVS='YES'.  This tell SRE-http to "store, and check,
additional privileges".

Assuming that CHECK_ADD_PRIVS='YES', entries can be added to the "dynamic
privileges" cache in two ways:

  1) Inclusion of a <!-- INTERPRET FILE ADDPRIVS.RXX  new_privs , duration -->
     keyphrase in a server-side-include capable HTML document, where:
        new_privs : a space delimited list of the "dynamic privileges" you wish
                   to add
       duration  : number of minutes these dynamic privileges will be
                   available.
      Basically, for the next "duration" minutes the "new_privs" privileges
      will be added to the "client privileges".

      These dynamic privileges are cumulative -- the client
      can accumulate a number of "dynamic privileges" by requesting
      documents containing varying INTERPRET FILE ADDPRIVS.RXX statements.


  2) Calling the SREF_ADD_PRIVS procedure from an external procedure.
       SREF_ADD_PRIVS should be called as:
          status=sref_add_privs(new_privs,duration)
       Where new_privs and duration are as above.

In both cases, when the client makes a subsequent request, the
"dynamic" new_privs are added to her static privileges.

  *** Actually, the dynamic privileges are based on the client's IP address.
  *** Therefore, they can be assigned to any individual -- even if there is
  *** no entry in SRE-http's username database (USERS.IN) for the client.

   Note: for security reasons, a slightly modified version
   of the new_privs are added -- the ADD_PRIVS_PREFIX is appended
   to the front of the new_privs. This is done to prevent unscrupulous
   individuals with limited access to your site (i.e.; the right to put
   documents in "personal" directories) from subverting access controls by
   sneakily requesting documents that contain:
        <!-- INTERPRET FILE ADDPRIVS.RXX SUPERUSER ,1000 -->


D) Examples

An Example (assuming that ADD_PRIVS_PREFIX='!'):

Assume the following access-control entries (in  ACCESS.IN)
    TEST/F1.HTM !P1
    TEST/F2.HTM !P2

and a T1.HTM file which includes the statement:
    <!-- INTERPRET FILE ADDPRIVS.RXX  P1 , 10 -->
and a T2.HTM file with
    <!-- INTERPRET FILE ADDPRIVS.RXX P1 P2 , 20 -->

A request for T1.HTM will cause a !P1 "dynamic privilege" to be added to the
client's privilege list (for the next 10 minutes).  Within this time
period, a request for F1.HTM will be honored, while a request for F2.HTM
will be not.

On the other hand, a request for T2.HTM  will enable subsequent access
(for the next 20 minute) to both F1.HTM and F2.HTM.

Notes:
 i) SREF_ADD_PRIVS also can be called with extra arguments,
    such as other IP addresses.  The full form is:
           status=sref_add_privs(new_privs,duration,verbose,port,
                                 host_nickname,user_address,enmadd)

 ii) The dynamic privileges are stored in _ADDPRIVS.80 (or .nnn,
     where nnn is the server port) in the GoServe "working" directory.