slapd upgrades don't add frontend ACLs for base="" and cn=subschema

Bug #571752 reported by Nathan Stratton Treadway
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openldap (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

As a result of LP: #427842, the initial configuration created upon installation of slapd 2.4.21-0ubuntu4 and later will include the following ACLs on the {-1}frontend database:
  olcAccess: to dn.base="" by * read
  olcAccess: to dn.base="cn=subschema" by * read

However, when upgrading from earlier versions of slapd, no attempt is made make sure these ACLs exist.

In the case of a Hardy -> Lucid upgrade, this causes e.g. "ldapvi --discover" to stop working.

Tags: hardy2lucid
Revision history for this message
Nathan Stratton Treadway (nathanst) wrote :

Based on hints found in the documents mentioned in bug #506317 and other places, I think the following three commands can be used to confirm that the permissions are set up correctly to allow various LDAP-related functionality to work:

Naming context discovery (e.g. "ldapvi --discover"):
  ldapsearch -x -H ldap://testhost/ -LLL -b "" -s base namingContexts

Determining supported SASL mechanisms:
  ldapsearch -x -H ldap://testhost/ -LLL -b "" -s base supportedSASLMechanisms

Retrieving the server's schema:
  ldapsearch -x -Hldap://testhost/ -b 'cn=Subschema' -s base '(objectClass=subschema)' attributetypes

I just ran a test and confirmed that those three commands return data when run against a stock Hardy slapd installation, but all three return no records when run against that same server immediately after a Hardy -> Lucid upgrade (when upgrading to slapd 2.4.21-0ubuntu5).

After manually adding the two lines
  olcAccess: {1}to dn.base="" by * read
  olcAccess: {2}to dn.base="cn=subschema" by * read
to the /etc/ldap/slapd.d/cn=config/olcDatabase\=\{-1\}frontend.ldif file
(just below the "olcAccess: {0}to * by dn.exact=gidNumber=0...." line) and restarting slapd, all three searches returned data again.

Revision history for this message
Nathan Stratton Treadway (nathanst) wrote :

I was also able to use "ldapmodify" to make the necessary changes:

* shut down slapd, removed the two lines I had added manually, restarted slapd, and confirmed that the three test searches were not returning any results

* created the file "frontend_acls.ldif" using the input lines given in bug #427842

* ran the command
  # ldapmodify -Y EXTERNAL -H ldapi:/// -f frontend_acls.ldif

As soon as I did that, the three test commands started returning data again.

Using ldapmodify instead of editing the {-1}frontend.ldif file directly has the advantage of allowing the LDAP server to work out the proper indexes for the olcAccess lines even if the user has added some such lines already. However ldapmodify requires that the slapd server be running, so it would probably be difficult to do from within the slapd.postinst script.

Chuck Short (zulcss)
Changed in openldap (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Ryan Tandy (rtandy) wrote :

Fixed in natty and later, looks like.

openldap (2.4.23-5) unstable; urgency=high
[...]
  * debian/slapd.scripts-common, debian/slapd.postinst: on upgrade from
    versions <= 2.4.23-4, explicitly grant access to cn=Subschema, which
    otherwise is blocked by our added olcAccess settings. Closes: #596326.
  * Likewise, grant access to dn.exact="" so that base dn autodiscovery
    works as intended. Closes: #596049.

Changed in openldap (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.