For informational purposes, here's additional detail as the subject and original problem description do not fully capture the extend of the problem. In all 2.x releases prior to 2.4.48 (I.e., 2.0.x, 2.1.x, 2.2.x, 2.3.x, and 2.4.x up to 2.4.47), the SASL security factor layer was set globally rather than per connection. So once a connection had been made that sets a SASL SSF, any and all non SASL connections would inherit that value.

If ACLs are used to limit access via setting restrictions with the sasl_ssf parameter, connections with no sasl_ssf could match those ACLs incorrectly.

For example,

access to * by users sasl_ssf=56 read by users tls_ssf=128 read by * none

Would allow a user who bound without any encryption full access to the database as long as one SASL connection had been made that had a minimum sasl_ssf value of 56.

Another contrived example:

access to attrs=userPassword by self sasl_ssf=56 =xw by * auth

Would allow a user to change their own password whether or not they had performed a SASL bind with a sasl_ssf of 56.

--Quanah

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com