[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: "break" broken?
The FAQ doesn't capture the intent of how ACL <control>s are to be
used. See tests/data/slapd-acl.conf for an example of how they
intended to be used (namely with additive permissions). These
are new to 2.0 and, obviously, documentation has yet to catch up.
But I do believe they work as intended.
Kurt
At 08:17 AM 5/30/01, David Olivier wrote:
>I am in the process of trying to understand the ACLs, as documented in the FAQ, <http://www.openldap.org/faq/data/cache/447.html>.
>
>(Thanks to the author of this FAQ! But I think it should appear in the "Software" section of the FAQ, rather than the "Developper's" section.)
>
>I'm on openldap 2.0.7. I have come upon some strange behaviour in the
>
> <control> ::= [ stop | continue | break ]
>
>clause, that doesn't seem to conform to what is said in that FAQ. I think it is a bug.
>
>In my tests, I attempt to bind as some entry I will call myBindDn; specifically:
>
> myBindDn = "uid=testAdm,ou=people,dc=univ-lyon2,dc=fr"
>
>For this, it appears from the FAQ and from my own tests that I need:
>
> privilege: "auth" ("x")
>
> to be granted on: myBindDn, attribute userPassword
>
> to: "anonymous".
>
>My first test is with the following ACLs:
>
>============== slapd.acl.conf: ======= (1)
>defaultaccess none
>
># First and only access clause:
>access to dn.base="uid=testAdm,ou=people,dc=univ-lyon2,dc=fr" attrs=userPassword
> by anonymous
> auth
>=========== End of slapd.acl.conf. === (1)
>
>Bind is successful, as expected.
>
>In my second test I just add a "break" clause:
>
>============== slapd.acl.conf: ======= (2)
>defaultaccess none
>
># First and only access clause:
>access to dn.base="uid=testAdm,ou=people,dc=univ-lyon2,dc=fr" attrs=userPassword
> by anonymous
> auth break
>=========== End of slapd.acl.conf. === (2)
>
>This time, bind fails! Error code 50, "Insufficient Access Rights". Note that these are all my ACLs; i.e. there is no other access clause after this one.
>
>Following the FAQ the meaning of "break" is:
>
>>You can also request that further analysis of this access clause (the
>><who>) be stopped here but keep on reading other access clauses. You do
>>this by specifying break. This is useful if you have clauses that match
>>this target later in your configuration and want to be able to
>>add or remove privileges.
>
>In other words, the only difference between test (1) and (2) is that after granting "anonymous" the "auth" privileges to myBindDn, the server should go on and analyze any further access clauses, to add or remove privileges. But here there are no more access clauses, so the "break" should have no effect! Instead, does have an effect: it cancels the privileges already granted.
>
>What makes me feel its a bug is that if I add to (2) another access clause:
>
>============== slapd.acl.conf: ======= (3)
>defaultaccess none
>
># First access clause:
>access to dn.base="uid=testAdm,ou=people,dc=univ-lyon2,dc=fr" attrs=userPassword
> by anonymous
> auth break
>
># Second access clause:
>access to dn.base="uid=testAdm,ou=people,dc=univ-lyon2,dc=fr" attrs=userPassword
> by dn.base="uid=smurgle,ou=people,dc=univ-lyon2,dc=fr"
> none
>=========== End of slapd.acl.conf. === (3)
>
>bind becomes successful again!
>
>Here, the <what> part of the second acces clause matches, but no <who> section applies. However, it seems that finding one more access clause where the <what> matches, even if no <who> section applies, is enough to make the "break" happy.
>
>This is confirmed by a fourth test, in which the <what> part doesn't match:
>
>============== slapd.acl.conf: ======= (4)
>defaultaccess none
>
># First access clause:
>access to dn.base="uid=testAdm,ou=people,dc=univ-lyon2,dc=fr" attrs=userPassword
> by anonymous
> auth break
>
># Second access clause:
>access to dn.base="uid=blotch,ou=people,dc=univ-lyon2,dc=fr" attrs=userPassword
> by dn.base="uid=smurgle,ou=people,dc=univ-lyon2,dc=fr"
> none
>=========== End of slapd.acl.conf. === (4)
>
>This time bind fails. The <what> in the second access clause does not match.
>
>If I am right about this being a BUG (big bad bug), I will put it in the ITS thing as such. But since I am not sure of myself I would like other people's opinions.
>
>I have tried my tests with "ACL debugging" on (loglevel 128). As far as I understand the messages, they seem to confirm my analysis: "break" needs another matching access clause to be happy.
>
>Workaround
>==========
>
>It seems one simple way to make "break" behave itself is to add a bogus access clause to the end of the ACLs, that will match any <what>, but apply to no <who>:
>
>============== workaround: =======
># Last access clause:
>access to *
> by dn.base="cn=No-One, o=no-org, c=Utopia"
> write
>======= End of workaround. =======
>
>With this added, cases (2) and (4) both become successful again.
>
>---
>David Olivier
>Klebs gardien Alpages CRI courrier brebis Lyon 2 Lumière