|Summary:||Authentication using PAM fails Signal 11|
|Product:||[Retired] Red Hat Linux||Reporter:||Joseph Tate <jtate>|
|Component:||postfix||Assignee:||John Dennis <jdennis>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Version:||9||CC:||bugzilla-redhat, chris.ricker, jeremyp|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-06-12 19:04:54 UTC||Type:||---|
|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: /usr/lib/sasl/smtpd.conf pwcheck_method: PAM /etc/pam.d/smtp 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 cyrus-sasl-2.1.10-4 pam-0.75-48 How reproducible: Every time Steps to Reproduce: 1. Configure postfix to run non-chroot by editing the two smtp lines in /etc/postfix/master.cf 2. Set up authentication as outlined at http://postfix.state-of-mind.de/patrick.koetter/smtpauth/smtp_auth_mailclients.html 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: 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 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. cyrus-sasl-md5-2.1.10-4 cyrus-sasl-2.1.10-4 cyrus-sasl-plain-2.1.10-4 cyrus-sasl-devel-2.1.10-4 cyrus-imapd-devel-2.1.12-15 cyrus-imapd-utils-2.1.12-15 postfix-2.0.9-4foo postfix-utils-2.0.9-4foo 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.