postfix-ldap is linked against gnuTLS

http://archives.neohapsis.com/archives/postfix/2007-01/1423.html

Interesting situation. Both postfix and postfix-ldap pick up their dependency on a TLS library from ${shlibs:Depends}, but get a different answer.

As Soren discovered, libldap2 depends on gnutls, while slapd on libssl.

Why do we have libldap2 agains gnutls? :)

I propose solution where we would leave libldap2 as is, but also build additional libldap2-nongpl (or some other name) which would be built against openssl. Then postfix and other non-GPL software could build against libldap2-nongpl.

Ante,
libldap2 exists only because we need to link to gnutls, so other packages don't inadvertently link to openssl, which is not compatible with the GPL. OpenLDAP2.4, which is in development will link to gnutls, so, we will no longer need openldap2 and this problem should go away.

-rick

So we have openldap 2.4 in Hardy. Can this get fixed now? Is it already?

On Mon, Apr 07, 2008 at 05:44:51PM -0000, Launchpad Bug Tracker wrote:

> When trying to get SSL and postfix and ldap going I stumbled accross the following:
> postfix-ldap is linked against gnu TLS and this breaks SSL and LDAP.
> postfix itself /is/ linked against openSSL.

> postmap works, but postfix will complain about 'bad search filter'

> See:
> http://archives.neohapsis.com/archives/postfix/2007-01/1351.html

> for the discussion.

This thread points to /usr/share/doc/postfix/TLS_README.gz, which claims:

 NOTE: Do not use Gnu TLS. It will spontaneously terminate a Postfix daemon
 process with exit status code 2, instead of allowing Postfix to 1) report
 the error to the maillog file, and to 2) provide plaintext service where
 this is appropriate.

But that is the extent of the explanation. This doesn't explain why postfix
(but no other ldap-using apps) manages to trigger this issue with GnuTLS.

I find three locations in the libgcrypt11 source where exit(2) is invoked.
Two of them are related to a failure to allocate secure memory. The third
is when an internal logging function is called with GCRY_LOG_FATAL. For the
most part, this seems to be called in the case of memory corruption errors,
or when keys that have just been generated fail to pass a self-test, or upon
failing to initialize a mutex, etc; while it's always unfriendly for a
library to ever call exit() directly, these are at least cases where the
library is in such an inconsistent state that it's probably dangerous to
continue, and if postfix is triggering any of these it's almost certainly a
bug in postfix that needs to be fixed.

The other case where I see log_fatal() being called that may be problematic
is when libgcrypt can't get any entropy. This could point to a real problem
of interactions between libgcrypt and libcrypto (GnuTLS/OpenSSL).

It would be helpful to capture the stderr output from this process before it
dies, since libgcrypt appears to log all fatal errors to stderr; that will
help narrow this down to a GnuTLS vs. Postfix bug.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Marking as 'incomplete' and unmilestoning. We still need the stderr output of a process that's failing in this way to diagnose whether it's a postfix or gnutls bug.

[15 Apr, @01:00 CEST, Steve Langasek wrote in "[Bug 81242] Re: postfix-ldap i ..."]
> Marking as 'incomplete' and unmilestoning. We still need the stderr
> output of a process that's failing in this way to diagnose whether it's
> a postfix or gnutls bug.

It will not be possible for me to provide this debugging output, as we
have switched to Exim for this particular implementation, and this is
now running production.

--
grtz,
 - Miek
 GPG Key ID: 3880 D0F6 http://www.miek.nl/

Thu GNU TLS library does exit_group(2) when no /dev/random (or /dev/urandom) is available (in the chroot, there isn't, so the TLS code for LDAP is broken). Wietse Venema wrote the explanation Steve Langasek quoted, because Wietse does not really like a library calling exit_group(2).

I'm not aware of any problems other than this one. For me adding /dev/u?random to the chroot would suffice.

> Marking as 'incomplete' and unmilestoning. We still need the stderr output of a
> process that's failing in this way to diagnose whether it's a postfix or gnutls bug.

IMHO it is a bug in both.
- GnuTLS is a library and therefore should not do fprintf(stderr,..) + exit, because printing to stderr isn't useful for a postfix child
- Postfix does not provide /dev/u?random in the chroot, triggering the issue.

So what is needed exactly? I currently have an LDAP installation failing due to this exact issue of being compiled against gnutls. Right now all I have is a debut level log output. Let me know if I might be able to supply more helpful information?

This is where ldap goes bad:

TLS: could not set cipher list SSLv3.
main: TLS init def ctx failed: -1
slapd destroy: freeing system resources.
slapd stopped.
connections_destroy: nothing to destroy.

Well, for one you could work around the issue using:

mkdir /var/spool/postfix/dev
cp -a /dev/random /dev/urandom /var/spool/postfix/dev

This should solve the exit_group(2) errors, as it did for me.
Of course the proper (read: permanent) fix would be to include this in
the init scripts, but this should work for now.

Brendan Martens schreef:
> So what is needed exactly? I currently have an LDAP installation failing
> due to this exact issue of being compiled against gnutls. Right now all
> I have is a debut level log output. Let me know if I might be able to
> supply more helpful information?
>
> This is where ldap goes bad:
>
> TLS: could not set cipher list SSLv3.
> main: TLS init def ctx failed: -1
> slapd destroy: freeing system resources.
> slapd stopped.
> connections_destroy: nothing to destroy.
>

I'm setting up some servers and workstations using Hardy, and just got bitten by this problem - default configuration of postfix is chrooted, postfix-ldap will not work against an LDAP server using SSL/TLS because the /dev/random and /dev/urandom devices are not present in the chroot, which prevents gnutls from initializing an SSL connection. It took me ages to find out what was wrong and how to work
around it.

Should the postfix package not be updated to mknod suitable devices in /var/spool/postfix/dev on installation?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Hoggarth schreef:
>
>
> Should the postfix package not be updated to mknod suitable devices in
> /var/spool/postfix/dev on installation?
>
That was the original point I made, yes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmUv78ACgkQ1C6FlsCYaHXCBgCePlYH3KGGZriFlKAD4UWmBvTP
SNAAnA5q5gFUEbHA3qJtlhXMPGjISVkC
=mKtw
-----END PGP SIGNATURE-----

For what it's worth this is still a problem in 10.04.1 and Postfix 2.7.0-1. Manually copying /dev/random and /dev/urandom to /var/spool/postfix/dev works around the problem.

I also find it quite strange that this doesn't affect more people. In fact this bug seems to have been completely forgotten. Is nobody using Postfix, LDAP and SSL/TLS on Ubuntu?

@Andreas,

Yes, I am using Postfix + LDAP, but I worked around this problem by running a local slapd that syncrepl's the relevant DB's over SSL, and then configured postfix to use ldap://127.0.0.1. It's far from elegant, but it does have the additional benefit that mail can still be accepted, even in the event the central LDAP server occasionally doesn't answer.

Still, it's sloppy that this has been an issue for about four(!) years now.

Just ran into this problem in lucid. Just wanted to leave a comment to point out that it's still an issue.

I still seem to have a problem solved by copying /dev/random to /var/spool/postfix/dev/random (urandom exists). This is on Precise with Postfix 12.04. I am using Postfix+LDAP+OpenSSL.