Red Hat Bugzilla – Bug 53615
Last modified: 2007-03-26 23:48:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010701
Description of problem:
The Roswell cyrus-sasl RPM's have the advantage of being broken up into
seprate SASL mechanisms. Hence, you should be able to install SASL to use
"gssapi" but not "plain" or use "plain" but not "md5" and so on. However,
it appears that the SASL library can and will successfully dynamically load
*.a libraries in additional to *.so. The result is that if cyrus-devel is
installed, ALL mechanisms are used despite what ones are choosen. Hence,
cyrus-devel should be similarily modularized or the *.a libraries should be
placed in a different location.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Remove or rename /etc/sasldb if there is one.
2.Install cyrus-sasl, cyrus-sasl-devel and ONLY *ONE* of the mechanism
3.Run saslpasswd to make a new sasldb entry.
4.Run sasldblistusers and note that additional mechanisms are being used
despite the RPM mechanisms not being installed
Actual Results: sasldblistusers shows:
user: testuser realm: testhost mech: PLAIN
user: testuser realm: testhost mech: CRAM-MD5
user: testuser realm: testhost mech: DIGEST-MD5
Expected Results: user: testuser realm: testhost mech: PLAIN
without any further entries (when cyrus-sasl-gssapi and cyrus-sasl-md5 are
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.
If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.
Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
I just assumed this would be a WONTFIX since April 31, 2004.
For SASL intensive applications, there have been recommendations available to
eliminate any unused SASL support libraries for squeezing out additional
performance. In my case, I was using a Cyrus-IMAPD with 26,000 users defined
along with Horde/IMP web interface which was generating several SASL
authentications. Part of the performance issue was later addressed by using the
software from IMAPProxy.org. Other work-around have also addressed the
performance problems we where having.
With RHEL 4, removing cyrus-sasl-md5 would also require rebuilding the openldap
package to not depend on the cyrus-sasl-md5 package. The amount of work
involved does not seem to warrant the amount of performance gained.
We are migrating away from RHEL due to a different performance consideration.
Under RHEL 3 we are using Reiserfs from kernel-unsupported because of the
advantages it provides over Ext3 when using maildir based IMAP server. While we
never expected or seeked support for such a configuration, we do expect to be
able to do updates without having to rebuild the kernels ourselves. The removal
of kernel-unsupported from RHEL 4 has created such a situation where Novell's
offering is considered to be the best migration path for this server.
I am fine with this bug being closed as CANTFIX or WONTFIX.