RE: saslauxprop and libldapdb, auxpropfunc error -7

[Igor Brezac <igor@ipass.net>]

On Thu, 6 Mar 2003, Howard Chu wrote:

> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Joe Rhodes
> > To: OpenLDAP-software@OpenLDAP.org
>
> > Greetings all:
> >
> > As background, I'm trying to get the libldap auxprop plugin
> > (distributed with OpenLDAP) for SASL to work.  The goal is to have
> > services that use SASL be able to use secure password exchanges
> > (DIGESTMD5, etc.) when the user account info is stored in OpenLDAP.
>
> > Running the Cyrus sample program, or the Cyrus IMAP server (which does,
> > BTW, authenticate OK with the sasldb plugin), I just keep getting the
> > auxpropfunc error -7.  I'm starting to wonder if perhaps my
> > configuration file for the server (in this case /etc/imapd.conf) is
> > wrong.  Would this keep the plugin from loading?  Below in my
> > imapd.conf file:
>
> > partition-default: /var/spool/imap
> > admins: cyrus root
> > sasl_pwcheck_method: auxprop
> > sasl_auxprop_plugin: libldapdb
> > ldapdb_uri: ldapi://127.0.0.1
> > ldapdb_id:  admin
> > ldapdb_pw: password
> > ldapdb_mech: PLAIN

Try (read 'man imapd.conf')

sasl_ldapdb_uri: ldapi://127.0.0.1
sasl_ldapdb_id:  admin
sasl_ldapdb_pw: password
sasl_ldapdb_mech: PLAIN

I am not sure about 'sasl_auxprop_plugin: libldapdb', it depends on how
you built libldapdb. Try to comment this out and let libsasl find it.


> I don't use Cyrus imapd normally, but I loaded it up to see what's going on.
> The reason libldapdb returns -7 (SASL_BADPARAM) is because it isn't getting
> any config info. That seemed a bit odd to me, but here's the deal - imapd
> does its own config file parsing, instead of using SASL's default config file
> loader. One of the things imapd does when it initializes the SASL library is
> to tell the SASL library to use imapd's own getopt function (SASL_CB_GETOPT
> callback), which operates with imapd's config file. In ldapdb, I always use
> whatever getopt() function is handed to the plugin in its utils pointer. I
> believe this is always libsasl's internal getopt() function. So, this is the
> first part of the problem; I need to check and see if the app has provided a
> callback, and use that instead. This is a quick fix in ldapdb.c.
>
> That's great, but in libsasl's _sasl_getcallback function, I find that
> libsasl *always* gives you libsasl's own getopt function when you retrieve
> the SASL_CB_GETOPT, even if the app tried to set its own. So after patching
> ldapdb.c, it still doesn't work. In fact, no SASL plugins can ever retrieve
> any configuration information when loaded in imapd, because they can't get
> access to imapd's getopt function.
>
> I believe this is a bug in libsasl - if the library never intends to let you
> replace its built-in getopt function, then supporting SASL_CB_GETOPT in the
> first place is meaningless. It should report an error if an app tries to set
> the callback, instead of quietly ignoring it, so that people don't have to
> bang their head against the wall for hours wondering why things don't work.
> Better still, it ought to actually use the callbacks that an app tells it to
> use.
>
> And by the way Joe, your config is wrong. Try:
>
> > sasl_auxprop_plugin: ldapdb
> > ldapdb_uri: ldap://127.0.0.1
>
> instead. The "ldapi://" scheme stands for LDAP over IPC, interprocess
> communication. It does not use IP addresses, it uses Unix domain sockets.
> Unix pathnames must be URL-escaped. E.g., if you wanted to use the socket
> /var/run/ldap you would use
> 	ldapdb_uri: ldapi://%2fvar%2frun%2fldap
>
> It's all a moot point for imapd until libsasl is fixed.
>
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
>
>

-- 
Igor