Provided by: freeradius-common_2.1.10+dfsg-3build2_all bug


       rlm_policy - FreeRADIUS Module


       The rlm_policy module implements a simple "policy" language.

       The policy language implemented by this module is simple, and specific to RADIUS.  It does
       not implement variables, arrays, loops, goto's, or any other feature of a  real  language.
       If those features are needed for your system, we suggest using rlm_perl.

       What  the  policy  module implements is a simple way to look for attributes in the request
       packet (or other places), and to add attributes to the  reply  packet  (or  other  places)
       based  on  those  decisions.   Where  the  module  shines is that it is significantly more
       flexible than the old-style users file.

       The module has one configuration item:

              The file where the policy is stored.


   Named policies
       The policy is composed of a series of named policies.  The  following  example  defines  a
       policy named "foo".

            policy foo {

       Policy  names MAY NOT be the same as attributes in the dictionary.  Defining a policy with
       the same name as a dictionary attribute will cause an error message to be printed, and the
       policy will not be loaded.

       When  the policy module is listed in a module section like "authorize", the module calls a
       policy named "authorize".  The "post-auth", etc. sections behave the  same.   These  names
       cannot be changed.

            include "policy.txt"

       The  filename  must  be  in  a  double-quoted string, and is assumed to be relative to the
       location of the current file.  If the filename ends with a '/', then it is assumed to be a
       directory, and all files in that directory will be read.

            include "dir/"

       All  file  in  "dir/" will be read and included into the policy definition.  Any dot files
       (".", "..", etc.) will not be included, however.

   Including multiple files
       The main file referred to from the radiusd.conf may include one or more other files, as in
       the following example.

   Referencing a named policy
       The  following  example  references  a  named  policy       foo()  While  the brackets are
       required, no arguments may be passed.

       "if" statements are supported.

            if (expression) {

       and "else"

            if (expression) {
            } else {

       also, "else if"

            if (expression) {
            } else if (expression) {

   Expressions within if statements
       Always have to have brackets around them.  Sorry.

       The following kinds of expressions may be used, with their meanings.

              TRUE if the referenced attribute exists, FALSE otherwise.  See below for details on
              attribute references.

              FALSE  if  the expression returned TRUE, and TRUE if the nested expression returned

       (attribute-reference == value)
              Compares the attribute to the value.  The operators here can be "==",  "!=",  "=~",
              "!~", "<", "<=", ">", and ">=".

       (string1 == string2)
              A  special  case  of the above.  The "string1" is dynamically expanded at run time,
              while "string2" is not.  The operators here can be "==", "!=", "=~",and  "!~".   Of
              these,  the  most useful is "=~', which lets you do things like ("%{ldap:query...}"
              =~ "foo=(.*) ").  The results of the regular expression match are  put  into  %{1},
              and can be used later.  See "doc/variables.txt" for more information.

       ((expression1) || (expression2))
              Short-circuit "or".  If expression1 is TRUE, expression2 is not evaluated.

       ((expression1) && (expression2))
              Short-circuit "and".  If expression1 is FALSE, expression2 is not evaluated.

              The  &&  and  ||  operators  have  equal precedence. You can't call a function as a

   Attribute references
       Attribute references are:

              Refers to an attribute of that name in  the  Access-Request  or  Accounting-Request
              packet.   May  also  refer  to  "server-side"  attributes, which are not documented

              An alternate way of referencing an attribute in the request packet.

              An attribute in the reply packet

              An attribute in the Access-Request  or  Accounting-Request  packet  which  will  be
              proxied to the home server.

              An  attribute  in  the Access-Accept or other packet which was received from a home

              An attribute in the per-request configuration and control attributes.   Also  known
              as "check" attributes (doc/variables.txt).

   Adding attributes to reply packet (or other location)
            reply .= {
                 attribute-name = value
                 attribute-name = value

       The first name can be "request", "reply", "control", "proxy-request", or "proxy-reply".

       The operator can be

        .= - appends attributes to end of the list

        := - replaces existing list with the attributes in the list (bad idea)

        = - use operators from "attribute = value" to decide what to do. (see "users")

       The block must contain only attributes and values.  Nothing else is permitted.


       authorize post-auth pre-proxy post-proxy




       radiusd(8), users(5), radiusd.conf(5)


       Alan DeKok <>

                                         7 December 2004                            rlm_policy(5)