Nick Milas wrote:
On 12/2/2012 5:23 ÎÎ, Michael StrÃder wrote:No! If one configures TLS support OpenLDAP must not start if any parameter has an invalid value. One could think about starting solely with LDAPI support to make back-config accessible.Thanks Michael, Let me ask, for clarification: If we have configured correctly TLS support, and yet we bind like: "ldapsearch -H ldap://"; but not using -ZZ, this doesn't mean that we will have a simple non-encrypted connection?
But what to do if a server configuration requires use of an encrypted connection? You're suggestion would require to temporarily enable encrypted connections which opens another can of worms.
In general I'm against adding more complexity to an implementation to *recover* from serious admin faults. I'm in favour of solely adding parameter validation to prevent admin faults. But this works only to some extent.
IMO your operational procedure should mandate that slapd has to be restarted to test if any parameter was changed which affects startup. Or better in your operational concept define a white-list of parameters allowed to be changed via back-config without restart.Any starting point for creating such a white-list of parameters?
The TLS parameters? ;-)
This ITS might also be interpreted that back-config should validate whether all the TLS-related files are actually readable. But this is tricky because slapd drops privileges after startup and at least the private key file is likely not be readable by the slapd demon user.A question on this: If the private cert is owned by root:root (and OpenLDAP runs under ldap) (chmod 640 or 600 for security), my experience shows that OpenLDAP will not read them (in CentOS, it is usually in "/etc/pki/tls/private". So, I am using a copy of the private key, owned only by ldap user, to make it readable by OpenLDAP. Should/could I do something different?
Yes, you're right. slapd's demon user already needs read access to the private key file. I've mixed it up with Apache's behaviour where the private key file can be owned by root and have permission 0600.
So back-config could check whether the TLS file parameter point to correct files (certs and keys) and refuse to change the attribute value. Still you can shoot yourself in the foot by moving away the files afterwards...
Ciao, Michael.