Upgrading from Cyrus SASLv1 to Cyrus SASLv2This document covers issues with upgrading from SASLv1 to SASLv2. To upgrade:
- Install Cyrus SASL v2 as normal according to the installation guide. This will overwrite some manpages, but will not affect your current applications. Do NOT attempt to make it use the same directories, otherwise old Cyrus SASLv1 applications will no longer function.
- Install your new Cyrus SASL v2 applications. Applications that use Cyrus SASLv1 will not use the Cyrus SASL v2 infrastructure (and vice-versa).
- If you used /etc/sasldb for authentication, you'll need
to take the following steps to convert to using /etc/sasldb2
with Cyrus SASL v2:
- run utils/dbconverter-2 after installation.
- change the pwcheck_method in any config files to auxprop
- (optional) add auxprop_plugin to the config files, set to sasldb
- If you used passwd, shadow, pam, kerberos_v4 or sia as your pwcheck_method in libsasl v1, you'll need to convert to using saslauthd. Arrange to start saslauthd -a method on boot. Change pwcheck_method in any configuration files to saslauthd.
- If you used pwcheck with libsasl v1, you can either continue to use pwcheck with libsasl v1 or you can switch to saslauthd, which offers more flexibility and a potentially much more efficient implementation.
- If you are continuing to use some libsasl v1 applications, read onwards to understand the ramifications.
- If you want to learn how to port applications from libsasl v1 to libsasl v2, you should read this document.
Likewise, the format for the sasldb database has been completely revamped. See here for a discussion of the relevant upgrade issues related to sasldb. All new passwords stored in the sasldb database will be in plaintext, meaning that a compromised sasldb will compromise all services with the same passwords. (This situation isn't significantly worse, cryptographicly speaking, than the old method and allows the database to be easy to transition to another format, when the need arises.) Mechanisms requiring a more secure password database backend (e.g. SRP) should implement their own or use alternate property names within sasldb.
Back to the index