<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2172/18/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/Named+ACLs">Named ACLs</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~mjordan">Matt Jordan</a>
</h4>
<br/>
<h4>Changes (31)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">{toc:maxLevel=3} <br> <br></td></tr>
<tr><td class="diff-unchanged" >h2. Overview <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Asterisk 11 introduces a new streamlined way for defining Access Control Lists (ACLs) to be shared among multiple consumers. Previously, ACLs had to be defined on a peer via some combination of permit and deny options which would compile together to create a complete ACL. This made defining ACLs for many users somewhat tedious with similar sets of rules and the method doesn't work well with Realtime consumers. To address these problems, we've added a means of creating ACL profiles which can be shared for multiple purposes by name. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Named ACLs introduce a new way to define Access Control Lists (ACLs) in Asterisk. Unlike traditional ACLs defined in specific module configuration files, Named ACLs can be shared across multiple modules. Named ACLs can also be accessed via the Asterisk Realtime Architecture (ARA), allowing for run-time updates of ACL information that can be retrieved by multiple consumers of ACL information. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2. Defining Named ACLs <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h2. Configuration <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Named ACLs can be defined in either the local named ACL configuration or in a database access via Asterisk's realtime configuration adapters ([more below|#realtime_acls]). In order to use them at all, an ACL configuration must be included in your defined astetcdir. Like all configurations for Asterisk, an example is included with the source in the configs directory which will be installed automatically when executing 'make samples'. Configuring named ACLs is relatively simple ans works more or less the same way as configuring ACLs by a consumer does. Some examples: <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h3. Static Configuration <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Named ACLs can be defined statically in _acl.conf_. Each context in _acl.conf_ defines a specific Named ACL, where the name of the context is the name of the ACL. The syntax for each context follows the permit/deny nomenclature used in traditional ACLs defined in a consumer module's configuration file. <br> <br>|| Option || Value || Description || <br>| deny | IP address [/Mask] || An IP address to deny, with an optional subnet mask to apply | <br>| permit | IP address [/Mask] || An IP address to allow, with an optional subnet mask to apply | <br> <br>h4. Examples <br> <br></td></tr>
<tr><td class="diff-unchanged" >{noformat} <br>; within acl.conf <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >{noformat} <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">multiple rules can be specified in an ACL just as before. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">Multiple rules can be specified in an ACL as well by chaining deny/permit specifiers. <br></td></tr>
<tr><td class="diff-unchanged" > <br>{noformat} <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >{noformat} <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">With ACL rules defined, we can then use those with our ACL consumers. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h3. ARA Configuration <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h2. Making consumers use Named ACLs <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">The ARA supports Named ACLs using the '*acls*' keyword in _extconfig.conf_. <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">The named ACL system is currently usable by Manager as well as current core level supported channel drivers which use ACLs (chan_sip and chan_iax2). Any configuration involving the permit/deny options is now joined by an acl option which can be used to add named ACLs to their access rules. For example: <br> <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">{noformat:title=Example Configuration} <br>;in extconfig.conf <br>acls => odbc,asterisk,acltable <br></td></tr>
<tr><td class="diff-unchanged" >{noformat} <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">; within sip.conf <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">[peer1] <br>;stuff <br>;deny=0.0.0.0/0.0.0.0 <br>;permit=127.0.0.1 <br>acl=name_of_acl_1 ; an ACL included from acl.conf that matches peer1's commented out permits/denies <br>{noformat} <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h4. Schema <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Any individual consumer of an ACL that uses the new functionality has an internal list of ACLs. Any number of ACLs can be placed within the list (barring duplicates of the same named ACL) and the rules set via permit/deny also comprise a separate ACL within the list (known as the base ACL). In the case of a list of ACLs with multiple individual rule sets (multiple named ACLs or named ACLs with a base ACL) being applied against an address, all of the ACLs are evaluated independently of the other rulesets and each ACL in the combined ruleset must allow the address individually in order for the combined list of ACLs to allow the address. To put it more concisely: <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">|| Column Name || Type || Description || <br>| name | varchar(80) | Name of the ACL | <br>| rule_order | integer | Order to apply the ACL rule. Rules are applied in ascending order. Rule numbers do not have to be sequential | <br>| sense | varchar(6) | Either 'permit' or 'deny' | <br>| rule | varchar(95) | The IP address/Mask pair to apply | <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">If a SIP peer has permit/deny rules and two named ACLs and a request to use that peer comes from an address which requires evaluation against that peer's ACL list and any one or more of those ACLs would have individually rejected the address, the address will be rejected outright just the same as if none of the ACLs had passed. Every ACL must be satisfied. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h4. Examples <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Like with permit/deny, multiple uses of acl can be used to specify multiple named ACLs. in addition to including multiple named ACLs that way though, you can simply separate individual named ACLs with commas. This makes named ACLs more viable use with realtime consumers of ACLs since a typical database table will only include one column for permit, one column for deny, and one column for acl options. Since only one option can be specified per permit/deny column (at the time of writing this document anyway), there isn't really a reliable or particularly useful way of creating ACLs for realtime peers without the use of named ACLs. Example: <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h5. Table Creation Script (PostgreSQL) <br></td></tr>
<tr><td class="diff-unchanged" > <br>{noformat} <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">;this <br>acl=named_acl_1 <br>acl=named_acl_2 <br>... <br>;is the same as: <br>acl=named_acl_1,named_acl_2 <br>{noformat} <br> <br>h2. ACL reloads <br> <br>ACLs are basically static once defined. Changing ACLs in the middle of a dialog could result in bad dialogs, hung calls, and other nasty stuff, so for the time being at least, when we want to change the ACLs that have been defined, we have to perform reloads across each of the consumers. Since we didn't want users to have to individually touch configuration files and perform reloads against each module just because they want to change ACL.conf, we issue events upon reloading the named ACL subsystem which causes cascading reloads on any consumers that are currently using named ACLs. Don't reload the ACL system if you don't want any consumers that are currently using it to perform reloads as well. <br> <br>Keep in mind that reloading many consumers will not result in the ACLs being applied immediately to any existing dialogs involving them. As such, don't treat the named ACL system like a dynamic means of blocking addresses. It's more of a tool for convenience and organization. It also makes diagnostics a little easier since it can isolate individual ACLs which were failed against for the purpose of applying an ACL. Asterisk is not a firewall and this isn't meant to provide the behavior of one. <br> <br>In order to reload the ACL subsystem, simply issue the CLI command: reload acl <br>If the acl.conf configuration has changed, the reload will be performed at this point and all consumers currently relying on it will also perform reloads. <br> <br>{anchor:realtime_acls} <br>h2. Realtime Named ACLs <br> <br>First, the extconfig name for ACLs is 'acls'. An example configuration would be the following: <br>{noformat} <br>;in extconfig.conf <br>acls => odbc,asterisk,acltable <br>{noformat} <br>'odbc' specifies the adapter. 'asterisk' is the profile the adapter uses in res_odbc.conf (since its using the odbc adapter) and 'acltable' is the name of the table on the database used to store the named ACLs. <br> <br>A typical named ACL database table contains the following columns: <br>name - up to 80 characters, name of the ACL (mandatory) <br>rule_order - integer. order that the rule appears in the ACL. Remember that the order of your permits/denies matters. It doesn't have to be numerically sequential (you can skip over numbers and all the rules will still be included in ascending order). (mandatory) <br>sense - characters. Either permit or deny. (mandatory) <br>rule - characters. the IP address/mask - the right side of the '=' in your typical permit/deny rule (mandatory) <br>systemname - characters. If the general acl.conf option 'systemname' is specified, only realtime ACLs with a matching systemname will be evaluated (optional) <br> <br>Example creation Script for pgsql: <br>{noformat} <br></td></tr>
<tr><td class="diff-unchanged" >CREATE TABLE acltable <br>( <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" > sense character varying(6) NOT NULL, <br> "rule" character varying(95) NOT NULL, <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;"> systemname charactervarying(80), <br></td></tr>
<tr><td class="diff-unchanged" > CONSTRAINT aclrulekey PRIMARY KEY (name, rule_order, rule, sense) <br>) <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >{noformat} <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">Example SQL statement made for SQLite3: <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h5. Table Creation Script (SQLite3) <br> <br></td></tr>
<tr><td class="diff-unchanged" >{noformat} <br>BEGIN TRANSACTION; <br></td></tr>
<tr><td class="diff-changed-lines" >CREATE TABLE acltable <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">(systemname</span> <span class="diff-added-words"style="background-color: #dfd;">(rule</span> TEXT, <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">rule TEXT,</span> sense TEXT, rule_order NUMERIC, name TEXT); <br></td></tr>
<tr><td class="diff-unchanged" >COMMIT; <br>{noformat} <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" > <br>{note}Since ACLs are grabbed by consumers at configuration, a realtime ACL won't automatically be up to date in statically defined consumers unless a reload is issued against the consumer. Realtime consumers (such as SIP/IAX2 peers) will similarly be up to date if and only if they have built the peer in question since the changes to the realtime ACL have taken place.{note} <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;"> <br>h2. Named ACL Consumers <br> <br>Named ACLs are supported by the following Asterisk components: <br>* Manager (IPv4 and IPv6) <br>* chan_sip (IPv4 and IPv6) <br>* chan_iax2 (IPv4 only) <br> <br>h3. Configuration <br> <br>A consumer of Named ACLs can be configured to use a named ACL using the _acl_ option in their ACL access rules. This can be in addition to the ACL rules traditionally defined in those configuration files. <br> <br>{noformat:title=Example 1: referencing a Named ACL} <br>; within sip.conf <br> <br>[peer1] <br>;stuff <br>;deny=0.0.0.0/0.0.0.0 <br>;permit=127.0.0.1 <br>acl=name_of_acl_1 ; an ACL included from acl.conf that matches peer1's commented out permits/denies <br>{noformat} <br> <br>Multiple named ACLs can be referenced as well by specifying a comma delineated list of Named ACLs to apply. <br> <br>{noformat:title=Example 2: multiple Named ACL references} <br>; within sip.conf <br> <br>[peer1] <br>;stuff <br>acl=named_acl_1,named_acl_2 <br>{noformat} <br> <br>Similarly, a SIP or IAX2 peer defined in ARA can include an '_acl_' column and list the Named ACLs to apply in that column. <br> <br>{note:title=NOTE} <br>Named ACLs can also be defined using multiple instances of the _acl_ keyword. This is discouraged, however, as the order in which ACLs are applied can be less obvious then the comma delineated list format. <br>{noformat} <br>acl=named_acl_1 <br>acl=named_acl_2 <br>{noformat} <br>{note} <br> <br>h3. ACL Rule Application <br> <br>Each module consumer of ACL information maintains, for each object that uses the information, a list of the defined ACL rule sets that apply to that object. When an address is evaluated for the particular object, the address is evaluated against each rule. For an address to pass the ACL rules, it must pass each ACL rule set that was defined for that object. Failure of any ACL rule set will result in a rejection of the address. <br> <br> <br>h2. Module Reloads <br> <br>ACL information is static once a consumer module references that information. Hence, changes in ACL information in an ARA backend will not automatically update consumers of that information. In order for consumers to receive updated ACL information, the Named ACL component must be reloaded. <br> <br>The Named ACL component supports module reloads, in the same way as other Asterisk components. When the Named ACL component is reloaded, it will issue a request to all consumers of Named ACLs. Those consumer modules will also be automatically reloaded. <br> <br>{warning:title=WARNING} <br>This implies that reloading the Named ACL component will force a reload of manager, chan_sip, etc. Only reload the Named ACL component if you want all consumers of that information to be reloaded as well. <br>{warning} <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<h2><a name="NamedACLs-Overview"></a>Overview</h2>
<p>Named ACLs introduce a new way to define Access Control Lists (ACLs) in Asterisk. Unlike traditional ACLs defined in specific module configuration files, Named ACLs can be shared across multiple modules. Named ACLs can also be accessed via the Asterisk Realtime Architecture (ARA), allowing for run-time updates of ACL information that can be retrieved by multiple consumers of ACL information.</p>
<h2><a name="NamedACLs-Configuration"></a>Configuration</h2>
<h3><a name="NamedACLs-StaticConfiguration"></a>Static Configuration</h3>
<p>Named ACLs can be defined statically in <em>acl.conf</em>. Each context in <em>acl.conf</em> defines a specific Named ACL, where the name of the context is the name of the ACL. The syntax for each context follows the permit/deny nomenclature used in traditional ACLs defined in a consumer module's configuration file. </p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Option </th>
<th class='confluenceTh'> Value </th>
<th class='confluenceTh'> Description </th>
</tr>
<tr>
<td class='confluenceTd'> deny </td>
<td class='confluenceTd'> IP address <span class="error">[/Mask]</span> </td>
<th class='confluenceTh'> An IP address to deny, with an optional subnet mask to apply </th>
</tr>
<tr>
<td class='confluenceTd'> permit </td>
<td class='confluenceTd'> IP address <span class="error">[/Mask]</span> </td>
<th class='confluenceTh'> An IP address to allow, with an optional subnet mask to apply </th>
</tr>
</tbody></table>
</div>
<h4><a name="NamedACLs-Examples"></a>Examples</h4>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>; within acl.conf
[name_of_acl1]
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1
</pre>
</div></div>
<p>Multiple rules can be specified in an ACL as well by chaining deny/permit specifiers.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>[name_of_acl2]
deny=10.24.0.0/255.255.0.0
deny=10.25.0.0/255.255.0.0
permit=10.24.11.0/255.255.255.0
permit=10.24.12.0/255.255.255.0
</pre>
</div></div>
<p>Named ACLs support common modifiers like templates and additions within configuration as well.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>[template_deny_all](!)
deny=0.0.0.0/0.0.0.0
[deny_all_whitelist_these](template_deny_all)
permit=10.24.20.1
permit=10.24.20.2
permit=10.24.20.3
</pre>
</div></div>
<h3><a name="NamedACLs-ARAConfiguration"></a>ARA Configuration</h3>
<p>The ARA supports Named ACLs using the '<b>acls</b>' keyword in <em>extconfig.conf</em>.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedHeader panelHeader" style="border-bottom-width: 1px;"><b>Example Configuration</b></div><div class="preformattedContent panelContent">
<pre>;in extconfig.conf
acls => odbc,asterisk,acltable
</pre>
</div></div>
<h4><a name="NamedACLs-Schema"></a>Schema</h4>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Column Name </th>
<th class='confluenceTh'> Type </th>
<th class='confluenceTh'> Description </th>
</tr>
<tr>
<td class='confluenceTd'> name </td>
<td class='confluenceTd'> varchar(80) </td>
<td class='confluenceTd'> Name of the ACL </td>
</tr>
<tr>
<td class='confluenceTd'> rule_order </td>
<td class='confluenceTd'> integer </td>
<td class='confluenceTd'> Order to apply the ACL rule. Rules are applied in ascending order. Rule numbers do not have to be sequential </td>
</tr>
<tr>
<td class='confluenceTd'> sense </td>
<td class='confluenceTd'> varchar(6) </td>
<td class='confluenceTd'> Either 'permit' or 'deny' </td>
</tr>
<tr>
<td class='confluenceTd'> rule </td>
<td class='confluenceTd'> varchar(95) </td>
<td class='confluenceTd'> The IP address/Mask pair to apply </td>
</tr>
</tbody></table>
</div>
<h4><a name="NamedACLs-Examples"></a>Examples</h4>
<h5><a name="NamedACLs-TableCreationScript%28PostgreSQL%29"></a>Table Creation Script (PostgreSQL)</h5>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>CREATE TABLE acltable
(
"name" character varying(80) NOT NULL,
rule_order integer NOT NULL,
sense character varying(6) NOT NULL,
"rule" character varying(95) NOT NULL,
CONSTRAINT aclrulekey PRIMARY KEY (name, rule_order, rule, sense)
)
WITH (
OIDS=FALSE
);
ALTER TABLE acltable OWNER TO asterisk;
GRANT ALL ON TABLE acltable TO asterisk;
)
</pre>
</div></div>
<h5><a name="NamedACLs-TableCreationScript%28SQLite3%29"></a>Table Creation Script (SQLite3)</h5>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>BEGIN TRANSACTION;
CREATE TABLE acltable (rule TEXT, sense TEXT, rule_order NUMERIC, name TEXT);
COMMIT;
</pre>
</div></div>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>These are just scripts generated by pgadmin III and SQLite Database Browser. They might not necessarily apply for your own setup.</td></tr></table></div>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Since ACLs are grabbed by consumers at configuration, a realtime ACL won't automatically be up to date in statically defined consumers unless a reload is issued against the consumer. Realtime consumers (such as SIP/IAX2 peers) will similarly be up to date if and only if they have built the peer in question since the changes to the realtime ACL have taken place.</td></tr></table></div>
<h2><a name="NamedACLs-NamedACLConsumers"></a>Named ACL Consumers</h2>
<p>Named ACLs are supported by the following Asterisk components:</p>
<ul>
<li>Manager (IPv4 and IPv6)</li>
<li>chan_sip (IPv4 and IPv6)</li>
<li>chan_iax2 (IPv4 only)</li>
</ul>
<h3><a name="NamedACLs-Configuration"></a>Configuration</h3>
<p>A consumer of Named ACLs can be configured to use a named ACL using the <em>acl</em> option in their ACL access rules. This can be in addition to the ACL rules traditionally defined in those configuration files.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedHeader panelHeader" style="border-bottom-width: 1px;"><b>Example 1: referencing a Named ACL</b></div><div class="preformattedContent panelContent">
<pre>; within sip.conf
[peer1]
;stuff
;deny=0.0.0.0/0.0.0.0
;permit=127.0.0.1
acl=name_of_acl_1 ; an ACL included from acl.conf that matches peer1's commented out permits/denies
</pre>
</div></div>
<p>Multiple named ACLs can be referenced as well by specifying a comma delineated list of Named ACLs to apply.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedHeader panelHeader" style="border-bottom-width: 1px;"><b>Example 2: multiple Named ACL references</b></div><div class="preformattedContent panelContent">
<pre>; within sip.conf
[peer1]
;stuff
acl=named_acl_1,named_acl_2
</pre>
</div></div>
<p>Similarly, a SIP or IAX2 peer defined in ARA can include an '<em>acl</em>' column and list the Named ACLs to apply in that column.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>NOTE</b><br />Named ACLs can also be defined using multiple instances of the <em>acl</em> keyword. This is discouraged, however, as the order in which ACLs are applied can be less obvious then the comma delineated list format.
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>acl=named_acl_1
acl=named_acl_2
</pre>
</div></div></td></tr></table></div>
<h3><a name="NamedACLs-ACLRuleApplication"></a>ACL Rule Application</h3>
<p>Each module consumer of ACL information maintains, for each object that uses the information, a list of the defined ACL rule sets that apply to that object. When an address is evaluated for the particular object, the address is evaluated against each rule. For an address to pass the ACL rules, it must pass each ACL rule set that was defined for that object. Failure of any ACL rule set will result in a rejection of the address.</p>
<h2><a name="NamedACLs-ModuleReloads"></a>Module Reloads</h2>
<p>ACL information is static once a consumer module references that information. Hence, changes in ACL information in an ARA backend will not automatically update consumers of that information. In order for consumers to receive updated ACL information, the Named ACL component must be reloaded.</p>
<p>The Named ACL component supports module reloads, in the same way as other Asterisk components. When the Named ACL component is reloaded, it will issue a request to all consumers of Named ACLs. Those consumer modules will also be automatically reloaded.</p>
<div class='panelMacro'><table class='warningMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/forbidden.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>WARNING</b><br />This implies that reloading the Named ACL component will force a reload of manager, chan_sip, etc. Only reload the Named ACL component if you want all consumers of that information to be reloaded as well.</td></tr></table></div>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/Named+ACLs">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=20189112&revisedVersion=3&originalVersion=2">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Named+ACLs?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>