BIND 10 #999: Integrate ACLs into b10-resolver

[BIND 10 Development]

#999: Integrate ACLs into b10-resolver
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  accepted
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110628
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:7 vorner]:

 > > I've been thinking about the same concept for #999 and tentatively
 > > defined a class named "Client":
 >
 > I didn't find the trac999 in git, so I couldn't have a look. But, do we
 really need accessor methods for something that just holds some data
 together? Anyway, it's not the main problem.
 >
 > I believe we need to integrate the two branches together sometime,
 otherwise registration of all the various checks will be problematic. I
 don't really care much about which class/struct is used as the context, I
 just put there the simplest think that looked it should work.

 I've pushed the latest trac999 code as trac999preview for reference.
 It's a complete implementation with full tests and documentation,
 although I don't think it a good target to review since it depends on
 some unclear points of #998.

 After looking at #769, I decided to not rely on it in order to reduce
 dependency.  Right now it has its own config parser/ACL loader as it
 only uses a very simple form of rules.  My intention is to get #998
 and this branch completed and merged, then to integrate the loader
 part of #999 with #769.  There will be some duplicate effort, but I
 thought this would be the fastest way to include the desired feature
 in the next release.

 The "Client" class is tentatively in the server_common module
 (directly), but I'm not strongly pushing it by doing so - it's a
 rather placeholder right now.  But as I said I thought ACl was not a
 good place for this concept either.  I'm not pushing the specific name
 of "Client" either - again it's tentative.

 > > I'm not sure how many things that depend on specific contexts would be
 > > reasonably defined under the acl namespace.  Also, the concept of
 > > "Packet" itself is not necessarily tied to access control.  By
 > > defining Client, I'd envision we'll eventually use it as a higher
 > > level interface between ASIO and actual (auth/resolver) server
 > > classes, that is, instead of getting a set of io_message,
 > > query_message, ... etc. in Resolver::processMessage(), we'd pass a
 > > "Client" object that encloses these types of parameters.
 >
 > Surely a good goal, I'm not against having the „context“ out of the ACL
 thing. I'd like to have a place where we put all the TSIG checks, etc,
 which is both ACL-related and DNS-related. The important part now is, I
 believe, using the singleton loader. As you mentioned, you expect to have
 this ready for review soon, this would be one of the TBD?

 Yeah, that's a middle term idea.

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