[bind10-dev] where and how do we plan to actually check ACLs?

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

Looking at ticket #766, I started to wonder if anything had been decided as to
the high-level issue of how we see acls work in general.

- From what I gathered in the jabber room, this is magically called somewhere, and
it would appear there was a sort of unspoken consensus that this is done on the
highest level within a module. I.e. a module gets a packet, runs it through one
(compound) ACL, and if it passes, starts to actually process it. The ACL would
contain all the needed information on whether whatever the sender tries to
achieve is allowed.

But that seems neither feasible nor extendable to me; the ACL's would need to
contain all knowledge about what any module can or cannot do (in order for it to
decide who is allowed to do what). It would also mean whatever input is passed
is parsed twice (once for the acl handling, and once to actually process the
input). It would also mean you'd have to configure specific allowances in
another location (your big acl) than where you would configure the feature in
the first place.

I think it should be feature-based; An 'ACL' as they are described now on the
wiki is really a (set of) identifiers, in which a certain third parties either
is or is not. They would have no meaning on their own, but they are tied to
features (like in bind9, allow-query, allow-notify, etc). So instead of checking
one big acl the moment a packet arrives, you start processing it, and check a
number of acls depending on what's actually in the packet ("I see your packet is
an UPDATE for zone foo.example. I see zone foo.example has been configured to
use this acl, this acl contains these adresses. You, sir, are not in this list.
I am disinclined to acquiesce to your request.") Note that one acl-point can
very well be whether a packet is accepted in the first place, without even
looking at what it wants to achieve.

In that sense, I think the result for #766 is that the properties the context
needs are really just source address and name of TSIG key. And perhaps
destination address and port, but I don't really see a lot of use for that.

It's very probable this view is shared by others, and that it just has been
assumed to be the case, or that is has simply not been aired yet. Or perhaps
everyone had this view all along and my week has simply been too long, and we
were talking past each other just now.

Which reminds me, I'm going offline for the next 3 days, you may discuss in the
meantime :)

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3yQ0AACgkQ4nZCKsdOncW/IwCfZJmS2Q1Nl94y7K7XRwyPGRnd
pDYAn37K/2vvquIQXzeuZPS48slZkqxm
=KwZx
-----END PGP SIGNATURE-----