Hi Sendmail folks,

We are currently noticing that our sendmail(sendmail-8.13) server is
dying with a SIGBUS when its trying to authenticate a client using
Cyrus-SASL AUTH mechanism.

===========================================
>From the further analysis on the core dunp, we got the following stack
trace,

#0 0xadb40 in __db_get_env () at db-4.2.52/db_method.c:359

#1 0xc0a15078 in _sasldb_getdata (utils=0x4009f548,
context=0x4009ea10,
auth_identity=0x4009f630 "root",
realm=0x4009f618 "xxx.yyy.zzz.com", propName=0x7af2664d
"userPassword",
out=0x7f7e47d8 "%d", max_out=<incomplete type>,
out_len=0x7f7e67d8) at db_berkeley.c:213

#2 0xc0a10028 in sasldb_auxprop_lookup (glob_context=0x0,
sparams=0x4009a600, flags=0, user=0x4009f421 "root", ulen=4)
at sasldb.c:114

#3 0x17867c in _sasl_auxprop_lookup () at cyrus-sasl-2.1.19/libsasl2/
auxprop.c:870

#4 0x17a76c in _sasl_canon_user () at
cyrus-sasl-2.1.19/libsasl2/canonusr.c:190

#5 0xc09c5434 in crammd5_server_mech_step2 (text=0x4009a3e0,
sparams=0x4009a600,
clientin=0x400a3ac0 "root 70c05ec529c2336a42807482287558d7",
clientinlen=37, serverout=0x7f7e3300, serveroutlen=0x7f7e33a8,
oparams=0x4009f270) at cram.c:259
(gdb)
=========================================

=> We also understood that, our sendmail is compiled with the archive
version of Berkeley DB "db-4.2.52" & Cyrus SASL shared libraries are
compiled with archive version of Berkeley DB "db-4.5.20"(Berkeley DB
versions are different).

When I compile sendmail with same version fo Berkeley DB as that of
Cyrus SASL, authentication went through fine as expected.

While browsing through sendmail.org for more information on this, I
got the following information mentioned in the README file,
====================================
If you use Berkeley DB for Cyrus SASL then you must compile sendmail
with the same version of Berkeley DB.
====================================

Can someone EXPLAIN MORE TECHNICALLY, why this is problem is happening
with Berkeley DB mismatch.

Appreciate an earliest reply to this.

Thanks a lot in advance.

Regards,
Sathya

In article <1190370192.470048.148430 [at] z24g2000prh.googlegroups.com>
Sathya <sathyasai.eshwar [at] gmail.com> writes:
>
>While browsing through sendmail.org for more information on this, I
>got the following information mentioned in the README file,
>====================================
> If you use Berkeley DB for Cyrus SASL then you must compile sendmail
>with the same version of Berkeley DB.
>====================================
>
>Can someone EXPLAIN MORE TECHNICALLY, why this is problem is happening
>with Berkeley DB mismatch.

I'm not sure why you have a problem understanding this... - a given
binary (program), sendmail in this case, can only use one version of a
given library (Berkeley DB in this case). So if the binary wants one
version of the library, and another library (SASL in this case) that the
program uses wants a different version of the same library, one of them
will lose.

If code built for one version of a library is run with a different
version, there may or may not be problems depending on if and how the
library API has changed between the versions (e.g. data structures
passed to/from functions have changed size, functions have
more/different parameters etc). For libraries with somewhat stable
functionality, it is often possible to have at least "backward
compatibility", i.e. code built for a given version of the library will
work when run with a newer version of the library.

However Berkeley DB is pretty notorious for changing the API in
non-compatible ways. This isn't *necessarily* a bad thing - if the
library functionality evolves, keeping compatibility can eventually lead
to a clumsy and suboptimal API - i.e. it's a tradeoff.

--Per Hedeland
per [at] hedeland.org

Hi Per Hedeland,

Thanks for quick response to this.

1. The primary intent of me asking this question is, as mentioned in
my previous post our sendmail-8.13.3 binary is compiled with an
archive version of Berkeley DB library, and so everytime the version
of Berkeley DB in Cyrus SASL is changed will result in sendmail's AUTH
functionality to be broken. So inorder to fix this issue, everytime I
need to recompile my sendmail binary by linking with the same Berkeley
DB version as that Cyrus SASL which we get it from thrid party.

I would be very happy if you would suggest a way to overcome this
issue with smooth migration.

2. I hope sendmail.org would have encountered the same issue earlier
which intended them to add the following quote in their README,
===================
> If you use Berkeley DB for Cyrus SASL then you must compile sendmail
> with the same version of Berkeley DB.
===================

It would be very helpful for me to understand the actual root cause of
the problem, if you could also explain the technical intent behind
this.(stack trace from core file is available in my previous post).

Thanks and regards,
Sathya

In article <1190450318.655616.326220 [at] 50g2000hsm.googlegroups.com> Sathya
<sathyasai.eshwar [at] gmail.com> writes:
>
>1. The primary intent of me asking this question is, as mentioned in
>my previous post our sendmail-8.13.3 binary is compiled with an
>archive version of Berkeley DB library, and so everytime the version
>of Berkeley DB in Cyrus SASL is changed will result in sendmail's AUTH
>functionality to be broken. So inorder to fix this issue, everytime I
>need to recompile my sendmail binary by linking with the same Berkeley
>DB version as that Cyrus SASL which we get it from thrid party.
>
>I would be very happy if you would suggest a way to overcome this
>issue with smooth migration.

The way to overcome it is to do what it says in the README - make sure
sendmail and SASL are built with same version of Berkeley DB. How you
make sure is up to you - for most people it's a non-issue since they
either use matching pre-built packages for sendmail and SASL, or build
both themselves, with the same set of libraries.

>It would be very helpful for me to understand the actual root cause of
>the problem, if you could also explain the technical intent behind
>this.(stack trace from core file is available in my previous post).

I already explained the root cause at length in the previous message,
which should also make clear that there is no "intent" behind it. Surely
you don't expect me or anyone else to get hold of the specific two
versions of Berkey DB involved in the particular instance of the problem
you reported, and analyze your core dump to find the exact API
difference that caused it. I wouldn't do that even it made sense, but in
this case the exercise is totally pointless - you already have the only
useful answer you need above.

--Per Hedeland
per [at] hedeland.org