[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
a faint glimmer of understanding on ACLs
I think I figured it out. I've had this feeling before twice only to be proven
wrong. <censored comments about ACLs, designers, hallucinogenics, and the
intersection of the three >
It appears that rules are matched on <what> and <who>. If the request matches
on <what> but fails on <who>, it punts to the default access rules. Only if
everything matches on the first rule does the ACL parsing look at the second
rule. A simple case illustrating this behavior follows:
Assume two ACLs:
access to dn="*,ou=gems,o=store" attrs=sn,entry
by addr="206.34.215.253" read
access to *
by dn="uid=Bruno,o=guardians,o=store" write
defaultaccess none
My expectation has been that if a rule fails, it will fall to the next rule.
Not true! The logs show otherwise:
=> access_allowed: entry (ou=rings, ou=Emeralds, ou=gems, o=store) attr (sn)
=> acl_get: entry (ou=rings, ou=Emeralds, ou=gems, o=store) attr (sn)
<= acl_get: [1] backend acl ou=rings, ou=Emeralds, ou=gems, o=store attr: sn
=> acl_access_allowed: search access to entry "ou=rings, ou=Emeralds, ou=gems,
o=store"
=> acl_access_allowed: search access to value "any" by
"UID=BRUNO,O=GUARDIANS,O=STORE"
<= acl_access_allowed: denied by default (no matching by)
as you can see, even though it passed both "by" clauses, access was still
denied because (I think) of the first <who> clause. To get the desired effect
(access to everything when binding to a dn, access to limited attributes entry
when binding from a host) I need ACL rules like:
access to dn="*,ou=gems,o=store" attrs=sn,entry
by addr="206.34.215.253" read
by dn="uid=Bruno,o=guardians,o=store" write
access to *
by dn="uid=Bruno,o=guardians,o=store" write
defaultaccess none
For some reason duplicating need by dn clause allows me access to everything
specified in the second rule set.
When I stand back and look at the behavior, it feels like a bug. I've written
enough ACLs for routers and firewalls to have a good feel for them. These ACLs
feel all wrong and either I need a new mindset to understand them or there's a
bug. I've glanced at the code and it's messy enough that I'm not entirely sure
what's going on. It will obviously take more study.
corrections to my misunderstandings gratefully accepted.
--- eric
Eric S Johansson esj@inguide.com esj@harvee.billerica.ma.us
This message was composed almost entirely by NaturallySpeaking.