Bug#299743: [exim-dev] [Debian #299743] exim4: Only try configured mechs in cyrus_sasl authenticator

[Juergen Kreileder]

Hi,

Matthew Byng-Maddick <exim@lists.colondot.net> writes:

> On Fri, Mar 18, 2005 at 04:15:59PM +0100, Marc Haber wrote:
>> Without having too much clue about SASL, I understand the reporter
>> that a SASL client is able to specify which mechanisms to use, and
>> exim doesn't specify that list, meaning that it uses "all", which
>> can clutter up the logs of the SASL server.
>
> The cyrus_sasl authenticator acts as a SASL server only. It has no
> way to specify where it gets the passwords from. On startup, it
> queries the SASL server to find all available mechanisms, as it
> won't advertise a mechanism that it doesn't know how to deal with.

Yes.  All the patch changes is that it limits the testing of the
available mechs to the ones actually used in the exim configuration.

>> The issue report for #299743 has a patch. Please consider this
>> patch.
>
> Oops, I thought you were referring to a patch for this problem. As
> far as I recall, I got my original code out of the Cyrus examples.
>
> I'm not sure what the solution is - I think the check is valuable,
> though it's probably possible to change it to backend onto a
> different database.  Unfortunately, I'm not an expert in Cyrus' SASL
> implementation.

The patch doesn't remove that check.

Here's what I see happening with three configured cyrus_sasl
authenticators configured (plain, login, cram-md5):

On startup auth_cyrus_sasl_init() gets called for each of these.
This means three calls to sasl_listmech() without a specified mech_list.
=> SASL tests which mechs of all available mechs actually work
=> three warnings about OTP not working
=> the returned list contains: plain, login, cram-md5, digest-md5, ...

With the patch, sasl_listmech() also gets called three times.  But now
SASL's mech_list option is set to the server_mech specified in the the
authenticator.  Or in other words, the answer from sasl_listmech()
gets limited to just the mech you're testing for (which is different
for each call.)
=> the return list contains just 'plain' or 'login', 'cram-md5' or
nothing depending on the value of ob->server_mech.

I've just tested the patch: Authentication still works fine,
unavailable mechs specified in the exim configuration are still
caught, and the auth.log warnings about OTP are gone.


        Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/