Univention Bugzilla – Bug 45571
(accidental) schema removal/upgrade may break (arbitrary) LDAP search - broken validation using slapschema
Last modified: 2021-06-16 11:24:35 CEST
Probably during an upgrade of ownCloud its .schema file got renamed or replaced. (The UDL ldap_extension module failed to properly activate the new schema file, but somehow disabled the old one?). In the end "owncloud82.schema" was no longer enabled. "slapschema" shows the attribute "ownCloudEnabled" as missing (printed as "OWNCLOUDENABLED"), but does *not* return an error value (see below). This lead to the strange situation, where "getend passwd Administrator" did not return anything, while "ldapsearch uid=Administrator" did find the user. The bug was finally traced to the LDAP indexes no longer working: `getent` / `nscd` / `libnssl-ldap` does a "(objectClass=posixAccount)" LDAP search, which no longer returned "uid=Administrator", which was validated by doing univention-ldapsearch '(&(objectClass=posixAccount)(uid=Administrator))' dn It also returned nothing. Calling "slapindex" also did not fix the problem. Doing a "slapcat | slapadd" finally showed the error: Unknown attribute "OWNCLOUDENABLED". Looking further: /etc/ldap/slapd.conf did not include /var/lib/univention-ldap/local-schema/owncloud82.schema. After doing an "udm settings/ldapschema modify --dn cn=owncloud82,cn=ldapschema,cn=univention --set active={FALSE,TRUE}" the schema was finally re-commited and included into "slapd.conf". After that "getent" again returned "Administrator". I testes it locally by removing the univention-app.schema: # slapschema ; echo $? ... 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPCONTACT" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPCONFLICTINGAPPS" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPWEBSITE" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPCATEGORY" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPDESCRIPTION" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPNAME" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPMAINTAINER" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPICON" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPDEFAULTPACKAGES" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPLONGDESCRIPTION" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPID" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPVERSION" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPWEBSITEMAINTAINER" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPSERVERROLE" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPINSTALLEDONSERVER" inserted. 59e9efb0 UNKNOWN attributeDescription "UNIVENTIONAPPUMCMODULENAME" inserted. ... 0 So the exit code of "slapschema" should not be trusted, but it is in base/univention-lib/python/ldap_extension.py: 443 »···»···»···»···# validate 444 »···»···»···»···p = subprocess.Popen(['/usr/sbin/slapschema', ], stdout=subprocess.PIPE, stderr=subprocess.STD… 445 »···»···»···»···stdout, stderr = p.communicate() 446 »···»···»···»···if p.returncode != 0: 447 »···»···»···»···»···ud.debug(ud.LISTENER, ud.ERROR, '%s: validation failed:\n%s.' % (name, stdout)) ... 460 »···»···»···»···»···return 461 »···»···»···»···ud.debug(ud.LISTENER, ud.INFO, '%s: validation successful.' % (name,)) ... 495 »···»···»···»···»···p = subprocess.Popen(['/usr/sbin/slapschema', ], stdout=subprocess.PIPE, stderr=subprocess… 496 »···»···»···»···»···stdout, stderr = p.communicate() 497 »···»···»···»···»···if p.returncode != 0:
PS: I remember a related problem, where a customer disabled an OpenLDAP overlay modules (memberof?), which provides an internal LDAP schema extension *when* enabled. After disabling the module, its LDAP attributes where still stored inside the MDB. Even after (temporarily) defining a custom schema extension re-using the same OID, deleting all references to that attribute, and removing the schema extension again, the MDB still contained a reference to the former attribute. Only after doing a full "slapcat | slapadd" dump/restore cycle the attribute was completely purged from the MDB file. OpenLDAP.org even somewhere states that "attribute removal" is not supported. So we should probably just prohibit schema removal.
If I understand the slapschema code correctly, the return code is the result from last checked ldap object? (Which might have no schema problem) ldap_extension.py now checks the stdout as well.
Code review: OK ucs-test: OK Manual tests: OK YAML: OK (fixed a typo: 36a2a720)
<http://errata.software-univention.de/ucs/4.3/357.html>