"break" broken?

[David Olivier <David.Olivier@univ-lyon2.fr>]

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