Bug 90412
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: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | bugzilla-redhat, chris.ricker, jeremyp |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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: | |
Embargoed: |
Description
Joseph Tate
2003-05-07 21:08:40 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. 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 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? 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. 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, my apologies. 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. |