Bug 68741 - sasldb not backwards compatible with Red Hat Linux 7.3
sasldb not backwards compatible with Red Hat Linux 7.3
Product: Red Hat Linux
Classification: Retired
Component: cyrus-sasl (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
Depends On:
Blocks: 62505 67217 79578
  Show dependency treegraph
Reported: 2002-07-13 06:35 EDT by Chris Ricker
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-10 01:37:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of sasldblistusers (3.01 KB, text/plain)
2002-07-13 06:36 EDT, Chris Ricker
no flags Details

  None (edit)
Description Chris Ricker 2002-07-13 06:35:32 EDT
sasldblistusers doesn't work, making using SASL basically impossible

[root@localhost root]# sasldblistusers
can't open /etc/sasldb
[root@localhost root]# ls -l /etc/sasldb 
-rw-------    1 root     root        12645 07-13 04:28 /etc/sasldb
[root@localhost root]# strings /etc/sasldb 
[root@localhost root]#
Comment 1 Chris Ricker 2002-07-13 06:36:16 EDT
Created attachment 65225 [details]
strace of sasldblistusers
Comment 2 Chris Ricker 2002-07-13 06:41:43 EDT
The /etc/sasldb which can't be read was created on RH 7.3.  From the trace, it
looks like perhaps the db format has changed:

2826  open("/etc/sasldb", O_RDONLY|O_LARGEFILE) = 3
2826  fstat64(3, {st_mode=S_IFREG|0600, st_size=12645, ...}) = 0
2826  flock(3, LOCK_SH|LOCK_NB)         = 0
2826  read(3, "\316\232W\23\0\20\0\0\0\20\0\0\0\20\0\0\n\0\0\0\0\20\0"..., 68) =
2826  read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4028)
 = 4028
2826  _llseek(3, 17592186048512, 0xbffff440, SEEK_SET) = -1 EINVAL (Invalid argu

If so, something needs to be provided to convert old sasldb files to the new
format, or SASL users will not be able to upgrade from RHL 7.x (SASL 1.5) to RHL
8 (SASL 2)
Comment 3 Chris Ricker 2002-07-13 06:43:17 EDT
On a RHL 7.3 box, this password db can be read just fine:

[kaboom@hanuman kaboom]$ sudo /usr/sbin/sasldblistusers 
user: kaboom-sasl realm: mail.oobleck.net mech: PLAIN
user: kaboom-sasl realm: mail.oobleck.net mech: DIGEST-MD5
user: kaboom-sasl realm: mail.oobleck.net mech: CRAM-MD5
[kaboom@hanuman kaboom]$ 
Comment 4 Chris Ricker 2002-07-14 13:32:57 EDT
I've renamed this because the problems not just with sasldblistusers.  I just
hit a problem with postfix choking (Bug 68800) because it couldn't read a sasldb
file from RH 7.3
Comment 5 Chris Ricker 2002-07-14 13:54:19 EDT
According to the SASL documentation (see

"If   you   are  using  /etc/sasldb  for  any  authentication,  run
utils/dbconverter-2 after installation."

dbconverter-2 is not included in the SASL packages, and the need to use it is
not documented in the RELEASE_NOTES.  Both of these have to be fixed, since they
are a change in backwards compatibility with prior releases.
Comment 6 Trond Eivind Glomsrxd 2002-07-24 16:11:16 EDT
Fixed in gdbm-1.8.0-18
Comment 7 Chris Ricker 2002-08-30 17:40:03 EDT
Reopening this -- dbconverter2 is still missing.

Because dbconverter2 is missing, I can't switch from sasldb to sasldb2 (which
applications written for SASL2 require instead of sasldb)
Comment 8 Chris Ricker 2002-08-31 10:33:27 EDT
Fixed component -- switching back to cyrus-sasl, since its what's missing utils
Comment 9 Nalin Dahyabhai 2002-09-02 19:46:04 EDT
Added dbconverter-2 to 2.1.7-2, along with note in bundled README.RPM.
Comment 10 Jay Turner 2002-09-03 07:27:11 EDT
Kaboom, are the new packages working for you now?
Comment 11 Chris Ricker 2002-09-03 09:05:44 EDT
I'll check tonight and see.  It should though -- I think the conversion utility
was the only thing I noticed missing for upgrading.

If anyone's handy with SASL experience, you might want to have them check as
well.  So far I've had zero luck getting the SASL2 / Postfix combo working using
sasldb2, even when I try from scratch (rather than upgrading)....  I'm not sure
if the problem is me, or SASL2, or the patch put into Postfix in 68800.

I have, in the past, gotten SASL2 / Postfix working using the patch in 68800,
but authenticating using saslauthd and system accounts, not sasldb2.  It'd be
helpful if someone could test, say, sendmail with sasldb2 and see if it's
generic, or at least specific to either Postfix or my stupidity ;-)

Also, someone *SERIOUSLY* needs to write up some documentation for RELEASE_NOTES
about all the changes between SASL1 and SASL2:

* configs in /usr/lib/sasl2 (not /usr/lib/sasl)
* different config file contents
* saslauthd
Comment 12 Trond Eivind Glomsrxd 2002-09-03 11:14:57 EDT
FWIW, I fixed it to work with the attached database early in this report.
Comment 13 Chris Ricker 2002-09-03 12:25:38 EDT
teg, you fixed sasldblistusers so it would read the attached file.  That's part
of the problem.

The rest of the problem is that there are two interfaces, SASL1 and SASL2. 
Software using SASL1 can read /etc/sasldb.
Software using SASL2 can read /etc/sasldb2.
They have different structures, etc....  Even if sasldblistusers can now read
old /etc/sasldb, you still have to run dbconverter2 to convert it to
/etc/sasldb2 (and then migrate configs from /usr/lib/sasl/ to /usr/lib/sasl2)
Comment 14 Chris Ricker 2002-09-04 10:04:19 EDT
Alright, I spent a lot of quality time last night with a debugger and got
Postfix / SASL / sasldb all straightened out.  Here's the basic situation, at
least regarding Postfix.

* null uses SASL-2.1 rpms which actually provide both SASL1 and SASL2 interfaces
* Postfix in null is actually compiled only to use the SASL1 interface

All this time, I'd been trying to get SASL2 going with it, and it wasn't working
because the Postfix RPM in null just doesn't do SASL2 correctly.  That's a
different bug, though, assuming its a bug at all (probably a re-open of Bug
68800 if so).

So, the question now is if:

1. any software in null actually uses the SASL2 interface?
2. or if everything should be using SASL2, and Postfix using SASL1 is a bug?
3. or if it all uses the SASL1 interface like Postfix does?

If it's 3, this bug is closed, though it's probably worth mentioning in the
/usr/share/doc/sasl-2* docs to avoid other people getting confused like me and
actually expecting the SASL clients to be using SASL2 interfaces.....

If it's 1 or 2, then the major subject of this bug (need for dbconverter2,
correct gdbm versions) is working, but documentation is needed in RELEASE_NOTES
about all the differences between SASL1 and SASL2.

Also, what's the policy regarding SASL1 vs SASL2?  Should Postfix be doing SASL2
or not?  If it should, I think it's probably just going to be a matter of
tweaking the Makefile (ie, trivial fix), though now that I have Internet access
I'll have to double-check 68800 and make sure I didn't submit the wrong patch,
which could also be why that's not working....
Comment 15 Chris Ricker 2002-09-04 12:32:57 EDT
Bug 67217 contains a patch for the postfix spec file to correct library linkages
to use SASL2.

FWIW, sendmail seems to support both SASL1 and SASL2.  I don't think that's
possible for postfix (the current code actually can do it, but upstream has
already removed SASL1 support entirely, so it's not viable long-term and will
make short-term maintenance relatively painful if bugfixes are necessary).

*shrug*  I'll shut up now before I wind up making this maze of inter-related
bugs even more complicated ;-).  I'd prefer that postfix go SASL2 personally,
but whatever the RH policy decision is is fine....  Whatever happens, though,
SASL RELEASE_NOTES documentation is needed.
Comment 16 Chris Ricker 2003-01-10 01:37:22 EST
Closing this -- the basic problem of missing dbconverter2 / db structure is fixed

Postfix still doesn't work w/ SASL2, but that's probably a separate bug and
there are plenty filed about it already

Note You need to log in before you can comment on or make changes to this bug.