SASL support in INN 2.5.0
julien at trigofacile.com
Fri Jun 26 05:48:59 UTC 2009
>> Consider for instance the Debian package which has SASL support. A
>> news client will see AUTHINFO SASL and try to authenticate with
>> AUTHINFO SASL PLAIN <base64-string>.
> Hm, shouldn't we be interrogating the SASL library for the supported
> mechanisms, and if PLAIN isn't supported, not including it?
Yes, it is what we do:
/* Check for available SASL mechanisms.
* Start the string with a space for the strstr() calls afterwards. */
sasl_listmech(sasl_conn, NULL, " ", " ", "", &mechlist, NULL, NULL);
I assumed in my example that it was installed.
> Or does the SASL library always report that PLAIN is supported?
No, I don't think so:
% aptitude show libsasl2-modules
Paquet : libsasl2-modules
Dépend : libsasl2-2 (= 2.1.22.dfsg1-8+etch1), libc6 (>= 2.3.6-6), libssl0.9.8 (>= 0.9.8c-1)
Suggère: libsasl2-modules-otp, libsasl2-modules-ldap, libsasl2-modules-sql, libsasl2-modules-gssapi-mit
Description : Pluggable Authentication Modules for SASL
This package provides the following SASL modules: LOGIN, PLAIN, ANONYMOUS, NTLM, CRAM-MD5, and DIGEST-MD5 (with DES support).
libsasl2-modules (which is a recommended package for inn2) should be installed.
The problem is that a user can have libsasl2-modules installed without wanting
it for his INN. Imagine libsasl2-modules is installed because of Postfix
or slapd (OpenLDAP); it would be automatically used by INN.
>> That's why I had imagined to have an sasl_auth: parameter in
>> readers.conf auth blocks. If set to true, then an AUTHINFO SASL
>> request will match this block if successful.
>> AUTHINFO SASL would not be advertised if there is no "sasl_auth: true"
>> in readers.conf.
> This does make sense to me.
OK, I will do that. It will solve the issue.
« Le chemin n'est pas difficile, c'est le difficile qui est le chemin. » (Kierkegaard)
More information about the inn-workers