Problem with "break" in ACLs (ITS#1187)

[David.Olivier@univ-lyon2.fr]

Full_Name: David Olivier
Version: 2.0.7
OS: Solaris 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (159.84.44.142)


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, specifically:

    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: uid=testAdm,ou=people,dc=univ-lyon2,dc=fr,
                     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 (<http://www.openldap.org/faq/data/cache/447.html>) 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 uid=testAdm,..., 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.

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.