[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Has anyone found a workaround? SASL/LDAP



> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Liviu Daia

> On 4 October 2003, Howard Chu <hyc@highlandsun.com> wrote:

> > Those experts are giving you outdated information, with no
> > understanding of the actual issues.

>     I don't consider myself an "expert" in either Postfix, OpenLDAP,
> or Cyrus SASL, but since I'm one of the guys that made the claim about
> Postfix Tony was referring to, I suppose I should step forward.
>
>     The way I see it:
>
> (1) The the pre-jail code of the smtp daemon in Postfix calls
>     sasl_client_init();
> (2) The LDAP dictionary in Postfix calls ldap_init(), which in turn
>     calls sasl_client_init() again;
> (3) In cyrus-sasl-2.1.15/lib/client.c we have:
>
>      64 static sasl_global_callbacks_t global_callbacks;
>      65
>      66 static int _sasl_client_active = 0;
> [...]
>     198 int sasl_client_init(const sasl_callback_t *callbacks)
>     199 {
>     200   int ret;
>     201   const add_plugin_list_t ep_list[] = {
>     202       { "sasl_client_plug_init", (add_plugin_t
> *)sasl_client_add_plugin },
>     203       { "sasl_canonuser_init", (add_plugin_t
> *)sasl_canonuser_add_plugin },
>     204       { NULL, NULL }
>     205   };
>     206
>     207   if(_sasl_client_active) {
>     208       /* We're already active, just increase our refcount */
>     209       /* xxx do something with the callback structure? */
>     210       _sasl_client_active++;
>     211       return SASL_OK;
>     212   }
>     213
>     214   global_callbacks.callbacks = callbacks;
>     215   global_callbacks.appname = NULL;
>
> (4) If both Postfix and OpenLDAP are linked dynamically against SASL,
>     you have a re-entrancy problem.
>
>     FWIW, Postfix also calls sasl_server_init() in the smtpd
> daemon, but
> that's not really relevant here.
>
>     If you can prove that any of (1)-(4) contain outdated information,
> or if you can enlighten me with a better understanding of the "actual
> issues", please do.

Considering that I am now using postfix 2.0.16 with Cyrus 2.1.15 and OpenLDAP
2.1 with my ldapdb auxprop, and both client and server SMTP AUTH work on the
same host, I think the facts speak for themselves. The code you quote in step
3 specifically addresses the re-entrancy issue and has been in Cyrus SASL
since April 2003 (Cyrus SASL 2.1.14).

Note in this log, the postfix process has no read access to /etc/sasldb2, and
yet the user is authenticated with CRAM-MD5 - this authentication was handled
by the ldapdb auxprop, not the sasldb auxprop:

Oct  5 23:06:37 viola postfix/smtpd[17255]: connect from
CELLO.mshome.net[192.168.0.1]
Oct  5 23:06:38 viola postfix/smtpd[17255]: warning: SASL authentication
problem: unable to open Berkeley db /etc/sasldb2: Permission denied
Oct  5 23:06:38 viola postfix/smtpd[17255]: 2602A3006D:
client=CELLO.mshome.net[192.168.0.1], sasl_method=CRAM-MD5,
sasl_username=testuser
Oct  5 23:06:38 viola postfix/cleanup[17257]: 2602A3006D:
message-id=<3F810737.2060704@symas.com>
Oct  5 23:06:38 viola postfix/smtpd[17255]: disconnect from
CELLO.mshome.net[192.168.0.1]
Oct  5 23:06:38 viola postfix/qmgr[17251]: 2602A3006D: from=<hyc@symas.com>,
size=598, nrcpt=1 (queue active)
Oct  5 23:06:38 viola postfix/smtp[17260]: 2602A3006D:
to=<hyc@cittern.symas.com>, relay=cittern.symas.com[192.168.1.2], delay=0,
status=sent (250 Ok: queued as A827E1C840)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support