BIND 10 #2066: general description on ACL in bind10 guide

[BIND 10 Development]

#2066: general description on ACL in bind10 guide
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120821
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  Core
  documentation                      |  Estimated Difficulty:  4
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:6 jinmei]:
 > - Personally, I'd like to see some formal definition of the ACL
 >   syntax like
 > {{{
 > acl = (rule(, rules...))
 > rule = {"action": "ACCEPT"|"REJECT"|"DROP" [, match [, matches...]]}
 > match = {"from": <ip_prefix> | "key": <tsig-keyname> | maybe-more-...}
 > }}}

 I tried to add some. But I'm not sure if it makes things easier or harder
 to
 understand. I always thought about the ACLs as objects, not as a language
 and
 the JSON being just a quite natural mapping of the objects to a string.

 > - the general description is a bit confusing to me in that it
 >   partially seems to talk about the concept while using specific data
 >   structure (i.e., JSON).  When we talk about the concept, it'd be
 >   more understandable to me if we use more commonly used conceptual
 >   terms like "a list" (although it's also used in the context of JSON)
 >   or "key value mapping", etc.  So, for example, the following general
 >   description would be more understandable to me:
 >   - an ACL is a list of rules
 >   - a rule is a set of key-value mappings
 >   - the set in a rule must always have exactly one special mapping
 >     called "action"
 >   - the set in a rule may have other mappings; they are called
 >     "matches".
 >   - (and explain how these apply in request processing)

 I tried to incorporate this.

 > - As noted in a commented-out "TODO", I think we need some description
 >   of keyring and a reference to it.

 Yes. But I believe this should go to a separate ticket.

 > - I think this note should be kept somewhere:
 > {{{#!diff
 > -      (Note the "add" in the first line.  Before this sequence, we
 > -      have had only entry in <varname>zones[0]/update_acl</varname>.
 > -      The <command>add</command> command with a value (rule) adds
 > -      a new entry and sets it to the given rule.
 > -
 > -      Due to a limitation of the current implementation, it doesn't
 > -      work if you first try to just add a new entry and then set it to
 > -      a given rule.)
 > }}}
 >   (although "we have had only entry" doesn't make sense to me...maybe
 >   the intent was "we have had no entry").

 I think I made this note irrelevant in one of the commits. The specs were
 missing default values for the items, which was wrong, so I fixed that
 instead
 of returning the note. Also, when #2184 (currently in review) is merged,
 the
 ACLs will act mostly sanely (so you will be able to do config add followed
 by
 config set action and config set address).

 However, I noticed other thing. It rejected the example with a new error,
 complaining that something is not a string and I found out it doesn't like
 the
 syntax with listing multiple possible values in a list. I believe that
 thing is
 a bug and possibly easy to fix (I guess there's false returned from
 somewhere
 instead of true in the definition of the IP check). OK to fix it, or
 should we
 just scratch the part about the lists?

 Also, I'm going to the vacations tomorrow (my) afternoon, so unless
 there's
 only very little to do, I can't finish the ticket now. Maybe someone can
 take
 it over?

-- 
Ticket URL: <http://bind10.isc.org/ticket/2066#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development