Man page of rlm_policy
rlm_policy
Section: FreeRADIUS Module (5)
Updated: 7 December 2004
Index of this MAN page
Back To MAN Pages From BackTrack 5 R1 Master List
NAME
rlm_policy - FreeRADIUS Module
DESCRIPTION
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:
- filename
-
The file where the policy is stored.
POLICY LANGUAGE
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.
Conditions
"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.
- (attribute-reference)
-
TRUE if the referenced attribute exists, FALSE otherwise. See below
for details on attribute references.
- (!(expression))
-
FALSE if the expression returned TRUE, and TRUE if the nested expression
returned FALSE.
- (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.
- Limitations.
-
The && and || operators have equal precedence. You can't call a
function as a expression.
Attribute references
Attribute references are:
- Attribute-Name
-
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 anywhere.
- request:Attribute-Name
-
An alternate way of referencing an attribute in the request packet.
- reply:Attribute-Name
-
An attribute in the reply packet
- proxy-request:Attribute-Name
-
An attribute in the Access-Request or Accounting-Request packet which
will be proxied to the home server.
- proxy-reply:Attribute-Name
-
An attribute in the Access-Accept or other packet which was received
from a home server.
- control:Attribute-Name
-
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.
SECTIONS
authorize
post-auth
pre-proxy
post-proxy
FILES
/etc/raddb/radiusd.conf
SEE ALSO
radiusd(8),
users(5),
radiusd.conf(5)
AUTHOR
Alan DeKok <aland@ox.org>
Index
- NAME
-
- DESCRIPTION
-
- POLICY LANGUAGE
-
- Named policies
-
- Including multiple files
-
- Referencing a named policy
-
- Conditions
-
- Expressions within if statements
-
- Attribute references
-
- Adding attributes to reply packet (or other location)
-
- SECTIONS
-
- FILES
-
- SEE ALSO
-
- AUTHOR
-
This document was created by
man2html,
using the manual pages.
Time: 07:34:21 GMT, September 13, 2011
Printable version of this article