Bug 90412

Summary: Authentication using PAM fails Signal 11
Product: [Retired] Red Hat Linux Reporter: Joseph Tate <jtate>
Component: postfixAssignee: John Dennis <jdennis>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: bugzilla-redhat, chris.ricker, jeremyp
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-12 19:04:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Joseph Tate 2003-05-07 21:08:40 UTC
Description of problem:
I've configured postfix to run non-chroot with PAM authentication through sasl:

pwcheck_method: PAM

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
postfix 1.1.11-11

How reproducible:
Every time

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.

Actual results:
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[14436]: warning: process
/usr/libexec/postfix/smtpd pid 14442 killed by signal 11
May  7 16:58:36 cheetah postfix/master[14436]: warning:
/usr/libexec/postfix/smtpd: bad command startup -- throttling

Expected results:
235 Authentication successful

Additional info:
Not sure if this is a postfix bug or a Red Hat bug.

Comment 1 John Dennis 2003-05-15 19:47:27 UTC
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.

Comment 2 Joseph Tate 2003-05-15 20:24:04 UTC
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.

Comment 3 John Dennis 2003-05-15 21:43:54 UTC
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
pam authenticate.

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?

Comment 4 Joseph Tate 2003-05-15 23:48:41 UTC
I'm using LDAP authentication, so I don't have the /etc/shadow problem.  The
smtpd.conf file in /usr/lib/sasl2/ contains
    pwcheck_method: saslauthd
    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
mode 400.

Let me know if you need more information.

Comment 5 Joseph Tate 2003-05-16 13:46:31 UTC
One more thing, I'm not running chroot, and I'm not running smpts.  My
configuration works for TLS over SMTP.

Comment 6 Chris Ricker 2003-05-20 05:06:13 UTC
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)

Comment 7 John Dennis 2003-05-20 14:23:13 UTC
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.

Comment 8 Joseph Tate 2003-05-20 14:43:17 UTC
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,
my apologies.

Comment 9 Chris Ricker 2003-05-20 15:44:06 UTC
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 ;-)

Comment 10 John Dennis 2003-06-12 19:04:54 UTC
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.