Red Hat Bugzilla – Bug 90412
Authentication using PAM fails Signal 11
Last modified: 2007-04-18 12:53:32 EDT
Description of problem:
I've configured postfix to run non-chroot with PAM authentication through sasl:
auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth
Version-Release number of selected component (if applicable):
Using RHL 9 with all updates applied
Steps to Reproduce:
1. Configure postfix to run non-chroot by editing the two smtp lines in
2. Set up authentication as outlined at
3. Edit /usr/lib/sasl/smtpd.conf as above
4. Test as outlined in the linked document above.
After running the AUTH PLAIN line as outlined in the linked document the
connection will close. /var/log/maillog will list:
May 7 16:58:36 cheetah postfix/master: warning: process
/usr/libexec/postfix/smtpd pid 14442 killed by signal 11
May 7 16:58:36 cheetah postfix/master: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling
235 Authentication successful
Not sure if this is a postfix bug or a Red Hat bug.
Just so you know, I've spent spent some time looking into this, it turns out to
be a little more involved than one might first imagine. I'm still tracking down
some of the issues and will update this bug as soon as I have an answer.
BTW, the 2.0.9 postfix RPM from http://tis.foobar.fi/software/?postfix does not
crash. I'm still using the default RH sasl packages.
I'm confused by one thing in your configuration. The postfix processes run as
user postfix, they do not have root privileges. Processes that access pam_unix
which is what happens when you use system-auth will try to read the shadow
password file, since this has root only access it should fail. I believe your
configuration will trip over this, postfix does not have the proper privilege to
The usual solution is to use a daemon with root privilege as an intermediary to
authenticate. The daemon would be saslauthd configured to use pam. Now it turns
out there seems to be problems with our saslauthd which is part of what I'm
trying to track down.
In the mean time I'm curious if the configuration you listed works with the
postfix 2.0.9 you mentioned and if so what is the user id of the postfix
processes and did you modify the permissions on the shadow password file?
I'm using LDAP authentication, so I don't have the /etc/shadow problem. The
smtpd.conf file in /usr/lib/sasl2/ contains
mech_list: plain login
I do not have a smtpd.conf file in /usr/lib/sasl
/usr/bin/saslauthd belongs to cyrus-sasl-2.1.10-4
These are the RPMS I have installed.
Here is a ps -aux | grep postfix
postfix 23142 0.0 0.4 6656 2064 ? S 16:54 0:00 [nqmgr]
postfix 23143 0.0 0.3 6576 1976 ? S 16:54 0:00 [tlsmgr]
postfix 23759 0.0 0.3 6564 1936 ? S 18:34 0:00 [pickup]
postfix 24109 0.0 0.6 7292 3152 ? S 19:45 0:00 [smtpd]
postfix 24110 0.0 0.3 6540 1920 ? S 19:45 0:00 [proxymap]
postfix 24111 0.0 0.3 6624 2024 ? S 19:45 0:00 [cleanup]
postfix 24112 0.0 0.3 6572 1944 ? S 19:45 0:00 [trivial-rewrite]
postfix 24113 0.0 0.3 4728 1580 ? S 19:45 0:00 [local]
postfix 24115 0.0 0.2 4508 1364 ? S 19:45 0:00 [pipe]
I have not tested with a user only in /etc/passwd and not in my LDAP directory,
so I can't verify or deny the problem with /etc/shadow. But my shadow file is
Let me know if you need more information.
One more thing, I'm not running chroot, and I'm not running smpts. My
configuration works for TLS over SMTP.
Isn't the basic solution here to recompile the cyrus-sasl shipped with RHL 9 to
include the saslauthd for cyrus-sasl 1.5? (ie, the problem is that you're trying
to use Postfix compiled with SASL1 support but saslauthd from SASL2)
Yes, that exactly is one of the problems I discovered when investiagating this
over the last couple of days. I've been in touch with the SASL maintainer to
work through some of the issues. Actually, its a bit more involved, the v1
version of the sasl library that postfix linked against had saslauthd support
ifdef'ed out during the build. Thus even though an incompatible v2 sasluthd
could have been run as a daemon, the library refused to talk to it because it
did not believe saslauthd was a supported authentication method. To make matters
slightly worse the protocol between the saslauthd client and server changed
between v1 and v2, thus the two are incompatible. I have rebuilt v1 sasl in my
private sandbox with saslauthd support enabled and have been testing with that,
I fully expected to work. But for reasons not yet known when saslauthd invokes
pam to authenitcate against the shadow password file pam fails the
authentication. The same user/password combination works with login/pam. I am
currently (amongst other issues) trying to track down why pam fails in this
configuration. I realize the original bug report was with a configuration using
LDAP authentication, but as starters pam/shadow as the most basic authentication
mechanism should be shown to work before proceding to test other mechanisms.
The good news is that LDAP is now finally linked against SASL v2 which in future
rpms will allow postfix to also link agains SASL v2.
The most common reason for the failure to authenticate is because /etc/passwd
and /etc/shadow are not replicated in the chroot. I know it's the simplest
mistake, but either make sure your postfix is not running chroot, or copy all
that's needed for auth into the chroot directory. If you've already done that,
Actually, Joseph, if you're using saslauthd and are chrooted, instead of copying
over passwd and shadow, it seemed to me I had to get the socket file for
saslauthd within the chroot (ie, /var/spool/postfix/var/run/saslauthd/mux and
friends), either by running multiple daemons or by bind mounts or similar. And
for chrooted, using saslauthd, and wanting saslauthd to use PAM, I had to get
all the PAM infrastructure inside the chroot as well....
It quickly becomes non-trivial, and more trouble than it's worth (since
unchrooted postfix is still not the weakest link on most systems ;-)
After investigation I concluded that there were a number of inherent conflicts
in the combination of postfix, sasl, and ldap versions. I'm not going to go into
a long winded explanation but the short answer is that we had been using v1 of
sasl and therein lied many problems. I will shortly release a postfix package
into rawhide that is based on sasl v2 and has been tested successfully with PAM
authentication. I expect the version will be postfix-2.0.11.
I have updated the /usr/share/doc/postfix-*/README-Postfix-SASL-RedHat.txt which
now describes authentication configuration, you may want to refer to it.