Un-document %{exec:foo}, as the documentation was wrong
[freeradius.git] / man / man5 / unlang.5
1 .\"     # DS - begin display
2 .de DS
3 .RS
4 .nf
5 .sp
6 ..
7 .\"     # DE - end display
8 .de DE
9 .fi
10 .RE
11 .sp
12 ..
13 .TH unlang 5 "01 Jul 2008" "" "FreeRADIUS Processing un-language"
14 .SH NAME
15 unlang \- FreeRADIUS Processing un\-language
16 .SH DESCRIPTION
17 FreeRADIUS supports a simple processing language in its configuration
18 files.  We call it an "un-language" because the intention is NOT to
19 create yet another programming language.  If you need something more
20 complicated than what is described here, we suggest using the Perl or
21 Python modules rlm_perl, or rlm_python.
22
23 The goal of the language is to allow simple policies to be written
24 with minimal effort.  Those policies are then applied when a request
25 is being processed.
26 .SH KEYWORDS
27 The keywords for the language are a combination of pre-defined
28 keywords, and references to loadable module names.  We document only
29 the pre-defined keywords here.
30
31 Subject to a few limitations described below, any keyword can appear
32 in any context.  The language consists of a series of entries, each
33 one one line.  Each entry begins with a keyword.  Entries are
34 organized into lists.  Processing of the language is line by line,
35 from the start of the list to the end.  Actions are executed
36 per-keyword.
37 .IP module-name
38 A reference to the named module.  When processing reaches this point,
39 the pre-compiled module is called.  The module may succeed or fail,
40 and will return a status to "unlang" if so.  This status can be tested
41 in a condition.  See the "Simple Conditions" text in the CONDITIONS
42 section, and MODULE RETURN CODES, below.
43
44 .DS
45         chap  # call the CHAP module
46 .br
47         sql   # call the SQL module
48 .br
49         ...
50 .DE
51 .IP if
52 .br
53 Checks for a particular condition.  If true, the block after the
54 condition is processed.  Otherwise, the block is ignored.  See
55 CONDITIONS, below, for documentation on the format of the conditions.
56
57 .DS
58         if (condition) {
59 .br
60                 ...
61 .br
62         }
63 .DE
64 .IP else
65 .br
66 Define a block to be executed only if the previous "if" condition
67 returned false.
68
69 .DS
70         else {
71 .br
72                 ...
73 .br
74         }
75 .DE
76 .IP elsif
77 .br
78 Define a block to be executed only if the previous "if" condition
79 returned false, and if the specified condition evaluates to true.
80
81 .DS
82         elsif (condition) {
83 .br
84                 ...
85 .br
86         }
87 .DE
88 .IP switch
89 .br
90 Evaluate the given string, and choose the first matching "case"
91 statement inside of the current block.  If the string is surrounded by
92 double quotes, it is expanded as described in the DATA TYPES section,
93 below.
94
95 No statement other than "case" can appear in a "switch" block.
96
97 .DS
98         switch "string" {
99 .br
100                 ...
101 .br
102         }
103 .DE
104 .IP case
105 .br
106 Define a static string to match a parent "switch" statement.  The
107 strings given here are not expanded as is done with the parent
108 "switch" statement.
109
110 A "case" statement cannot appear outside of a "switch" block.
111
112 .DS
113         case string {
114 .br
115                 ...
116 .br
117         }
118 .DE
119
120 A default entry can be defined by omitting the static string.  This
121 entry will be used if no other "case" entry matches.  Only one default
122 entry can exist in a "switch" section.
123
124 .DS
125         case {
126 .br
127                 ...
128 .br
129         }
130 .DE
131 .IP update
132 .br
133 Update a particular attribute list, based on the attributes given in
134 the current block.
135
136 .DS
137         update <list> {
138 .br
139                 attribute = value
140 .br
141                 ...
142 .br
143         }
144 .DE
145
146 The <list> can be one of "request", "reply", "proxy-request",
147 "proxy-reply", or "control".  The "control" list is the list of
148 attributes maintainted internally by the server that controls how the
149 server processes the request.  Any attribute that does not go in a
150 packet on the network will generally be placed in the "control" list.
151
152 For backwards compatibility with older versions, "check" is accepted
153 as a synonym for "control".  The use of "check" is deprecated, and
154 will be removed in a future release.
155
156 For EAP methods with tunneled authentication sessions (i.e. PEAP and
157 EAP-TTLS), the inner tunnel session can also reference
158 "outer.request", "outer.reply", and "outer.control".  Those references
159 allow you to address the relevant list in the outer tunnel session.
160
161 The only contents permitted in an "update" section are attributes and
162 values.  The contents of the "update" section are described in the
163 ATTRIBUTES section below.
164 .IP redundant
165 This section contains a simple list of modules.  The first module is
166 called when the section is being processed.  If the first module
167 succeeds in its operation, then the server stops processing the
168 section, and returns to the parent section.
169
170 If, however, the module fails, then the next module in the list is
171 tried, as described above.  The processing continues until one module
172 succeeds, or until the list has been exhausted.
173
174 Redundant sections can contain only a list of modules, and cannot
175 contain keywords that perform conditional operations (if, else, etc)
176 or update an attribute list.
177
178 .DS
179         redundant {
180 .br
181                 sql1    # try this
182 .br
183                 sql2    # try this only if sql1 fails.
184 .br
185                 ...
186 .br
187         }
188 .DE
189 .IP load-balance
190 This section contains a simple list of modules.  When the section is
191 entered, one module is chosen at random to process the request.  All
192 of the modules in the list should be the same type (e.g. ldap or sql).
193 All of the modules in the list should behave identically, otherwise
194 the load-balance section will return different results for the same
195 request.
196
197 Load-balance sections can contain only a list of modules, and cannot
198 contain keywords that perform conditional operations (if, else, etc)
199 or update an attribute list.
200
201 .DS
202         load-balance {
203 .br
204                 ldap1   # 50% of requests go here
205 .br
206                 ldap2   # 50% of requests go here
207 .br
208         }
209 .DE
210
211 In general, we recommend using "redundant-load-balance" instead of
212 "load-balance".
213 .IP redundant-load-balance
214 This section contains a simple list of modules.  When the section is
215 entered, one module is chosen at random to process the request.  If
216 that module succeeds, then the server stops processing the section.
217 If, however, the module fails, then one of the remaining modules is
218 chosen at random to process the request.  This process repeats until
219 one module succeeds, or until the list has been exhausted.
220
221 All of the modules in the list should be the same type (e.g. ldap or
222 sql).  All of the modules in the list should behave identically,
223 otherwise the load-balance section will return different results for
224 the same request.
225
226 Load-balance sections can contain only a list of modules, and cannot
227 contain keywords that perform conditional operations (if, else, etc)
228 or update an attribute list.
229
230 .DS
231         redundant-load-balance {
232 .br
233                 ldap1   # 50%, unless ldap2 is down, then 100%
234 .br
235                 ldap2   # 50%, unless ldap1 is down, then 100%
236 .br
237         }
238 .DE
239 .SH CONDITIONS
240 The conditions are similar to C conditions in syntax, though
241 quoted strings are supported, as with the Unix shell.
242 .IP Simple
243 conditions
244 .br
245 .DS
246         (foo)
247 .DE
248
249 Evalutes to true if 'foo' is a non-empty string (single quotes, double
250 quotes, or back-quoted).  Also evaluates to true if 'foo' is a
251 non-zero number.  Note that the language is poorly typed, so the
252 string "0000" can be interpreted as a numerical zero.  This issue can
253 be avoided by comparings strings to an empty string, rather than by
254 evaluating the string by itself.
255
256 If the word 'foo' is not a quoted string, then it can be taken as a
257 reference to a named attribute.  See "Referencing attribute lists",
258 below, for examples of attribute references.  The condition evaluates
259 to true if the named attribute exists.
260
261 Otherwise, if the word 'foo' is not a quoted string, and is not an
262 attribute reference, then it is interpreted as a reference to a module
263 return code.  The condition evaluates to true if the most recent
264 module return code matches the name given here.  Valid module return
265 codes are given in MODULE RETURN CODES, below.
266 .IP Negation
267 .DS
268         (!foo)
269 .DE
270
271 Evalutes to true if 'foo' evaluates to false, and vice-versa.
272 .PP
273 Short-circuit operators
274 .RS
275 .br
276 .DS
277         (foo || bar)
278 .br
279         (foo && bar)
280 .DE
281
282 "&&" and "||" are short-circuit operators.  "&&" evaluates the first
283 condition, and evaluates the second condition if and only if the
284 result of the first condition is true.  "||" is similar, but executes
285 the second command if and only if the result of the first condition is
286 false.
287 .RE
288 .IP Comparisons
289 .DS
290         (foo == bar)
291 .DE
292
293 Compares 'foo' to 'bar', and evaluates to true if the comparison holds
294 true.  Valid comparison operators are "==", "!=", "<", "<=", ">",
295 ">=", "=~", and "!~", all with their usual meanings.  Invalid
296 comparison operators are ":=" and "=".
297 .PP
298 Conditions may be nested to any depth, subject only to line length
299 limitations (8192 bytes).
300 .SH DATA TYPES
301 There are only a few data types supported in the language.  Reference
302 to attributes, numbers, and strings.  Any data type can appear in
303 stand-alone condition, in which case they are evaluated as described
304 in "Simple conditions", above.  They can also appear (with some
305 exceptions noted below) on the left-hand or on the right-hand side of
306 a comparison.
307 .IP Numbers
308 Numbers are composed of decimal digits.  Floating point, hex, and
309 octal numbers are not supported.  The maximum value for a number is
310 machine-dependent, but is usually 32-bits, including one bit for a
311 sign value.
312 .PP
313 word
314 .RS
315 Text that is not enclosed in quotes is interpreted differently
316 depending on where it occurs in a condition.  On the left hand side of
317 a condition, it is interpreted as a reference to an attribute.  On the
318 right hand side, it is interpreted as a simple string, in the same
319 manner as a single-quoted string.
320
321 Using attribute references permits limited type-specific comparisons,
322 as seen in the examples below.
323
324 .DS
325         if (User-Name == "bob") {
326 .br
327                 ...
328 .br
329         if (Framed-IP-Address > 127.0.0.1) {
330 .br
331                 ...
332 .br
333         if (Service-Type == Login-User) { 
334 .DE
335 .RE
336 .IP "strings"
337 .RS
338 Double-quoted strings are expanded by inserting the value of any
339 variables (see VARIABLES, below) before being evaluated.  If
340 the result is a number it is evaluated in a numerical context.
341
342 String length is limited by line-length, usually about 8000
343 characters.  A double quote character (") can be used in a string via
344 the normal back-slash escaping method.  ("like \\"this\\" !")
345 .RE
346 .IP 'strings'
347 Single-quoted strings are evaluated as-is.  Their values are not
348 expanded as with double-quoted strings above, and they are not
349 interpreted as attribute references.
350 .IP `strings`
351 Back-quoted strings are evaluated by expanding the contents of the
352 string, as described above for double-quoted strings.  The resulting
353 command given inside of the string in a sub-shell, and taking the
354 output as a string.  This behavior is much the same as that of Unix
355 shells.
356
357 Note that for security reasons, the input string is split into command
358 and arguments before variable expansion is done.
359
360 For performance reasons, we suggest that the use of back-quoted
361 strings be kept to a minimum.  Executing external programs is
362 relatively expensive, and executing a large number of programs for
363 every request can quickly use all of the CPU time in a server.  If you
364 believe that you need to execute many programs, we suggest finding
365 alternative ways to achieve the same result.  In some cases, using a
366 real language may be sufficient.
367 .IP /regex/i
368 These strings are valid only on the right-hand side of a comparison,
369 and then only when the comparison operator is "=~" or "!~".  They are
370 regular expressions, as implemented by the local regular expression
371 library on the system.  This is usually Posix regular expressions.
372
373 The trailing 'i' is optional, and indicates that the regular
374 expression match should be done in a case-insensitive fashion.
375
376 If the comparison operator is "=~", then parantheses in the regular
377 expression will define variables containing the matching text, as
378 described below in the VARIABLES section.
379 .SH VARIABLES
380 Run-time variables are referenced using the following syntax
381
382 .DS
383         %{Variable-Name}
384 .DE
385
386 Note that unlike C, there is no way to declare variables, or to refer
387 to them outside of a string context.  All references to variables MUST
388 be contained inside of a double-quoted or back-quoted string.
389
390 Many potential variables are defined in the dictionaries that
391 accompany the server.  These definitions define only the name and
392 type, and do not define the value of the variable.  When the server
393 receives a packet, it uses the packet contents to look up entries in
394 the dictionary, and instantiates variables with a name taken from the
395 dictionaries, and a value taken from the packet contents.  This
396 process means that if a variable does not exist, it is usually because
397 it was not mentioned in a packet that the server received.
398
399 Once the variable is instantiated, it is added to an appropriate
400 attribute list, as described below.  In many cases, attributes and
401 variables are inter-changeble, and are often talked about that way.
402 However, variables can also refer to run-time calls to modules, which
403 may perform operations like SQL SELECTs, and which may return the
404 result as the value of the variable.
405 .PP
406 Referencing attribute lists
407 .RS
408 Attribute lists may be referenced via the following syntax
409
410 .DS
411         %{<list>:Attribute-Name}
412 .DE
413
414 Where <list> is one of "request", "reply", "control", "proxy-request",
415 "proxy-reply", or "outer.request", "outer.reply", "outer.control",
416 "outer.proxy-request", or "outer.proxy-reply". just as with the
417 "update" section, above.  The "<list>:" prefix is optional, and if
418 omitted, is assumed to refer to the "request" list.
419
420 When a variable is encountered, the given list is examined for an
421 attribute of the given name.  If found, the variable reference in the
422 string is replaced with the value of that attribute.  Some examples are:
423
424 .DS
425         %{User-Name}
426 .br
427         %{request:User-Name} # same as above
428 .br
429         %{reply:User-Name}
430 .br
431         %{outer.reqest:User-Name} # from inside of a TTLS/PEAP tunnel
432 .DE
433 .RE
434 .PP
435 Results of regular expression matches
436 .RS
437 If a regular expression match has previously been performed, then the
438 special variable %{0} will contain a copy of the input string.  The
439 variables %{1} through %{8} will contain the substring matches,
440 starting from the left-most parantheses, and onwards.  If there are
441 more than 8 parantheses, the additional results will not be placed
442 into any variables.
443 .RE
444 .PP
445 Obtaining results from databases
446 .RS
447 It is useful to query a database for some information, and to use the
448 result in a condition.  The following syntax will call a module, pass
449 it the given string, and replace the variable reference with the
450 resulting string returned from the module.
451
452 .DS
453         %{module: string ...}
454 .DE
455
456 The syntax of the string is module-specific.  Please read the module
457 documentation for additional details.
458 .RE
459 .PP
460 Conditional Syntax
461 .RS
462 Conditional syntax similar to that used in Unix shells may also be
463 used.
464 .IP %{%{Foo}:-bar}
465 If %{Foo} has a value, returns that value.
466 .br
467 Otherwise, returns literal string "bar".
468 .IP %{%{Foo}:-%{Bar}}
469 If %{Foo} has a value, returns that value.
470 .br
471 Otherwise, returns the expansion of %{Bar}.
472
473 These conditional expansions can be nested to almost any depth, such
474 as with %{%{One}:-%{%{Two}:-%{Three}}}
475 .RE
476 .PP
477 String lengths and arrays
478 .RS
479 Similar to a Unix shell, there are ways to reference string lenths,
480 and the second or more instance of an attribute in a list.  If you
481 need this functionality, we recommend using a real language.
482 .IP %{#string}
483 The number of characters in %{string}.  If %{string} is not
484 set, then the length is not set.
485
486 e.g. %{#Junk-junk:-foo} will yeild the string "foo".
487 .IP %{Attribute-Name[index]}
488 Reference the N'th occurance of the given attribute.  The syntax
489 %{<list>:Attribute-Name[index]} may also be used.  The indexes start
490 at zero.  This feature is NOT available for non-attribute dynamic
491 translations, like %{sql:...}.
492
493 For example, %{User-Name[0]} is the same as %{User-Name}
494
495 The variable %{Cisco-AVPair[2]} will reference the value of the
496 THIRD Cisco-AVPair attribute (if it exists) in the request packet,
497 .IP %{Attribute-Name[#]}
498 Returns the total number of attributes of that name in the relevant
499 attribute list.  The number will usually be between 0 and 200.
500
501 For most requests, %{request:User-Name[#]} == 1
502 .IP %{Attribute-Name[*]}
503 Expands to a single string, with the value of each array
504 member separated by a newline.
505 .IP %{#Attribute-Name[index]}
506 Expands to the length of the string %{Attribute-Name[index]}.
507 .SH ATTRIBUTES
508 The attribute lists described above may be edited by listing one or
509 more attributes in an "update" section.  Once the attributes have been
510 defined, they may be referenced as described above in the VARIABLES
511 section.
512
513 The following syntax defines attributes in an "update" section.  Each
514 attribute and value has to be all on one line in the configuration
515 file.  There is no need for commas or semi-colons after the value.
516
517 .DS
518         Attribute-Name = value
519 .DE
520 .PP
521 Attribute names
522 .RS
523 The Attribute-Name must be a name previously defined in a dictionary.
524 If an undefined name is used, the server will return an error, and
525 will not start.
526 .RE
527 .IP Operators
528 The operator used to assign the value of the attribute may be one of
529 the following, with the given meaning.
530 .RS
531 .IP =
532 Add the attribute to the list, if and only if an attribute of the same
533 name is already present in that list.
534 .IP := 
535 Add the attribute to the list.  If any attribute of the same name is
536 already present in that list, its value is replaced with the value of
537 the current attribute.
538 .IP +=
539 Add the attribute to the tail of the list, even if attributes of the
540 same name are already present in the list.
541 .RE
542 .PP
543 Enforcement and Filtering Operators
544 .RS
545 The following operators may also be used in addition to the ones
546 listed above.  Their function is to perform enforcement or filtering
547 on attributes in a list.
548 .IP -=
549 Remove all matching attributes from the list.  Both the attribute name
550 and value have to match in order for the attribute to be removed from
551 the list.
552 .IP ==
553 Remove all non-matching attributes from the list.  Both the attribute
554 name and value have to match in order for the attribute to remain in
555 the list.
556
557 Note that this operator is very different than the '=' operator listed
558 above!
559 .IP <=
560 Enforce that the integer value of the attribute is less than or equal
561 to the value given here.  If there is no attribute of the same name in
562 the list, the attribute is added with the given value, is with "+=".
563 If an attribute in the list exists, and has value less than given
564 here, it's value is unchanged.  If an attribute in the list exists,
565 and has a value greater than given here, then that value is replaced
566 with the one given here.
567
568 This operator is valid only for attributes of integer type.
569 .IP >=
570 Enforce that the integer value of the attribute is greater than or
571 equal to the value given here.  If there is no attribute of the same
572 name in the list, the attribute is added with the given value, is with
573 "+=".  If an attribute in the list exists, and has value greater than
574 given here, it's value is unchanged.  If an attribute in the list
575 exists, and has value less than given here, then that value is
576 replaced with the one given here.
577
578 This operator is valid only for attributes of integer type.
579 .RE
580 .IP Values
581 .br
582 The format of the value is attribute-specific, and is usually a
583 string, integer, IP address, etc.  Prior to the attribute being
584 instantiated, the value may be expanded as described above in the DATA
585 TYPES section, above.  This flexibility means that, for example, you
586 can assign an IP address value to an attribute by specifying the IP
587 address directly, or by having the address returned from a database
588 query, or by having the address returned as the output of a program
589 that is executed.
590
591 When string values are finally assigned to a variable, they can have a
592 maximum length of 253 characters.  This limit is due in part to both
593 protocol and internal server requirements.  That is, the strings in
594 the language can be nearly 8k in length, say for a long SQL query.
595 However, the output of that SQL query should be no more than 253
596 characters in length.
597 .SH OTHER KEYWORDS
598 Other keywords in the language are taken from the names of modules
599 loaded by the server.  These keywords are dependent on both the
600 modules, and the local configuration.
601
602 Some use keywords that are defined in the default configuration file
603 are:
604 .IP fail
605 Cause the request to be treated as if a database failure had occurred.
606 .IP noop
607 Do nothing.  This also serves as an instruction to the configurable
608 failover tracking that nothing was done in the current section.
609 .IP ok
610 Instructs the server that the request was processed properly.  This
611 keyword can be used to over-ride earlier failures, if the local
612 administrator determines that the faiures are not catastrophic.
613 .IP reject
614 Causes the request to be immediately rejected
615 .SH MODULE RETURN CODES
616 When a module is called, it returns one of the following codes to
617 "unlang", with the following meaning.
618
619 .DS
620         notfound        information was not found
621 .br
622         noop            the module did nothing
623 .br
624         ok              the module succeeded
625 .br
626         updated         the module updated the request
627 .br
628         fail            the module failed
629 .br
630         reject          the module rejected the request
631 .br
632         userlock        the user was locked out
633 .br
634         invalid         the configuration was invalid
635 .br
636         handled         the module has handled the request itself
637 .DE
638
639 These return codes can be tested for in a condition, as described
640 above in the CONDITIONS section.
641 .SH FILES
642 /etc/raddb/radiusd.conf
643 .SH "SEE ALSO"
644 .BR radiusd.conf (5),
645 .BR dictionary (5)
646 .SH AUTHOR
647 Alan DeKok <aland@deployingradius.com>