Problems with include in acl file

[Robert Moskowitz]

Mark Andrews wrote:
> In message <4ADB44A5.2060602 at htt-consult.com>, Robert Moskowitz writes:
>   
>> Chris Thompson wrote:
>>     
>>> On Oct 18 2009, Joseph S D Yao wrote:
>>>
>>>       
>>>> On Sat, Oct 17, 2009 at 10:33:37PM -0400, Robert Moskowitz wrote:
>>>>         
>>>>> I am trying to build up an environment where the user can maintain 
>>>>> custom files and leave the basic files alone.
>>>>>
>>>>> So I have a named.acl that works, I add an include line:
>>>>>
>>>>> acl "hdanets" {
>>>>>         192.168.1.0/24; // hda network
>>>>>         include "custom.acl";
>>>>> };
>>>>>
>>>>>
>>>>> and get the error:
>>>>>
>>>>> Starting named:
>>>>> Error in named configuration:
>>>>> named.acl:3: missing ';' before '"'
>>>>>           
>>>> ...
>>>>
>>>>
>>>> Glancing through the 9.6 ARM <https://www.isc.org/files/Bv9.6ARM.pdf>,
>>>> it seems to me that "include" is a statement, and needs to be parsed
>>>> outside of any other statements, not inside a statement.  
>>>>         
>>> That's what it *says* ... but it is being economical with the truth!
>>>
>>>       
>>>>                                                          Inside the
>>>> "acl" statement the parser would expect to see IP addresses, networks in
>>>> the ip.ad.dr.ess/xx format, keys with the name prepended by the keyword
>>>> "key", and the names of other ACLs.  When it encounters the word
>>>> "include" in this context, it parses it as the name of an ACL - after
>>>> which, the '"' is out of place.
>>>>         
>>> As long ago as BIND 9.2, you'll find this in the CHANGES file:
>>>
>>> 764.   [func]          Configuration files now allow "include" directives
>>>                        in more places, such as inside the "view" 
>>> statement.
>>>                        [RT #377, #728, #860]
>>>
>>> Roughly, "include" can occur instead of a keyword in any list where all
>>> list elements are introduced by keywords; e.g. "view", "options", 
>>> "logging",
>>> "zone". But not "acl" because the elements there do not (in general) 
>>> start
>>> with keywords.
>>>       
>> Oh, fiddlesticks!!!!  ;)'
>>
>> This complicates matters.  It would have made it very easy to bootstrap 
>> into this process if this was supported.
>>     
>
> acl's can include other acls.
> I'm having a hard time seeing why you need to include a file here.
>
> include "custom.acl";	// defines acl "customacl"
>
> acl "hdanets" {
> 	92.168.1.0/24; // hda network
> 	customacl;
> };
>   

Neat.

Though I solved the problem by having 2 includes in named.conf, for 
named.acl and custom.acl.  Then in the view, I listed two variables:  
hdanets; customnets

So is the case of six of one, half-a-dozen of the other?  That is they 
are equal solutions to this situation?

As for why I am doing this, hdanets.acl is built by the system's script 
that I have no control over.  It will contain what the script has on my 
internal networks.  It only supports one network.  But some users of 
this system (like me) have a number of internal networks that we want to 
be able to access this system, so custom.acl is outside of the 
controlling script and can be maintained by an informed installer, like 
me.  There is also a custom-zone.conf and custom-n2a.zone and 
custom-a2n.zone...

As we improve the system, there will be less need for these, but I 
believe they will always be needed.

Oh, the system this is for is AMAHI.ORG.

>   
>>> For the whole truth, you need to look at lib/isccfg/namedconf.c and
>>> lib/isccfg/parser.c and work out in exactly which cases cfg_parse_mapbody
>>> in the latter gets called :-( 
>>>       
>> I am not much into reading c code.  I never really programmed in c.  Did 
>> do some programming in b....
>>
>> So reading someone elses script and recommending changes has been 
>> challenging enough!
>>
>>
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>