Red Hat Bugzilla – Bug 469594
Can't get SASL to use passwords already in passwd database via PAM
Last modified: 2009-07-14 10:13:01 EDT
Created attachment 322253 [details]
My /etc/mail/sendmail.mc configuration
Description of problem:
I'm configuring sendmail to use SASL2 for authentication, and using saslauthd (from cyrus-sasl) for the SASL authentication. I've got SASL configured to look in PAM for authentication (which is how it ships out of the box with Fedora 9). I'd like SASL to automatically accept any username/password pair for any valid user account on my machine, but that doesn't seem to work, and I can't figure out how to make it do that. Instead, I have to manually add every such username/password pair to the SASL2 database with saslpasswd2. I'm guessing there must be a better way, but I can't figure it out.
I've read all the docs that I can find. I've done countless Google searches and read many web pages on how to configure sendmail/sasl, but none of them discuss this issue. Perhaps there is an obvious way to do this that I'm overlooking? This may be a documentation issue.
It seems like it would be nice to have some documentation that explains how to set this up. Even better would be to make this the default, as I suspect this is going to be the most desirable way for it to behave out of the box.
The rest of the configuration went smoothly and the defaults were appreciated. Configuration of dovecot was especially pleasant: thank you so much for setting such great config defaults as a starting point.
Version-Release number of selected component (if applicable):
# ls -l /etc/sysconfig/saslauthd /usr/lib64/sasl2/Sendmail.conf /etc/pam.d/smtp*
lrwxrwxrwx 1 root root 25 2008-10-09 18:49 /etc/pam.d/smtp -> /etc/alternatives/mta-pam
-rw-r--r-- 1 root root 72 2008-03-29 05:20 /etc/pam.d/smtp.sendmail
-rw-r--r-- 1 root root 433 2008-11-02 14:09 /etc/sysconfig/saslauthd
-rw-r--r-- 1 root root 25 2008-03-29 05:20 /usr/lib64/sasl2/Sendmail.conf
# head /etc/sysconfig/saslauthd /usr/lib64/sasl2/Sendmail.conf /etc/pam.d/smtp*
==> /etc/sysconfig/saslauthd <==
# Directory in which to place saslauthd's listening socket, pid file, and so
# on. This directory must already exist.
# Mechanism to use when checking passwords. Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.
# Additional flags to pass to saslauthd on the command line. See saslauthd(8)
# for the list of accepted flags.
==> /usr/lib64/sasl2/Sendmail.conf <==
==> /etc/pam.d/smtp <==
auth include system-auth
account include system-auth
==> /etc/pam.d/smtp.sendmail <==
auth include system-auth
account include system-auth
All of these files are at their defaults (I believe). I'm attaching my /etc/mail/sendmail.mc file as well in case it is relevant.
Have you tried using 'pwcheck_method:pam' ?
Doh! No, I didn't think to try that. I don't know how I missed it.
However, I tried it just now, and it doesn't seem to help, at least as far as I could tell. Here's what I did. First, I changed /usr/lib64/sasl2/Sendmail.conf to use pwcheck_method:pam. Here's the result:
# cat /usr/lib64/sasl2/Sendmail.conf
I deleted the entry that I had earlier manually added to the SASL2 database, so that I would have a clean (empty) SASL2 database, and verified that it did not contain any users:
# saslpasswd2 -d daw
Then, I restarted sendmail and saslauthd:
# service sendmail restart; service saslauthd restart
Then, I tried authenticating to sendmail and sending mail. I used the Claws 3.5.0 IMAP client. I tried all three authentication methods it supports (CRAM-MD5, LOGIN, and AUTH); none of them worked. In each case I got an authentication failure.
Then I added my user account back to the SASL2 database manually:
# saslpasswd2 -c daw
[[password prompts deleted]]
And I tried using Claws to authenticate to sendmail and send a piece of email, which succeeded this time (even though Sendmail.conf still contains pwcheck_method:pam).
Of course, it wouldn't surprise me if I've made some other mistake or form of pilot error this time.
Sorry for the lengthy question/explanations, and thanks again for your help.
Is there any further information I can provide to help troubleshoot this?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.