Bug 469594 - Can't get SASL to use passwords already in passwd database via PAM
Can't get SASL to use passwords already in passwd database via PAM
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: cyrus-sasl (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jan F. Chadima
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-02 18:58 EST by D. Wagner
Modified: 2009-07-14 10:13 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 10:13:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
My /etc/mail/sendmail.mc configuration (7.21 KB, text/plain)
2008-11-02 18:58 EST, D. Wagner
no flags Details

  None (edit)
Description D. Wagner 2008-11-02 18:58:14 EST
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):

cyrus-sasl-lib-2.1.22-15.fc9.i386
cyrus-sasl-lib-2.1.22-15.fc9.x86_64
cyrus-sasl-plain-2.1.22-15.fc9.x86_64
cyrus-sasl-md5-2.1.22-15.fc9.x86_64
cyrus-sasl-devel-2.1.22-15.fc9.x86_64
cyrus-sasl-2.1.22-15.fc9.x86_64
sendmail-8.14.2-4.fc9.x86_64
sendmail-cf-8.14.2-4.fc9.x86_64
sendmail-doc-8.14.2-4.fc9.x86_64
perl-Authen-SASL-2.10-2.fc9.noarch


Additional info: 

# 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.
SOCKETDIR=/var/run/saslauthd

# 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.
MECH=pam

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.

==> /usr/lib64/sasl2/Sendmail.conf <==
pwcheck_method:saslauthd

==> /etc/pam.d/smtp <==
#%PAM-1.0
auth       include	system-auth
account    include	system-auth

==> /etc/pam.d/smtp.sendmail <==
#%PAM-1.0
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.
Comment 1 Tomas Mraz 2008-11-03 03:17:00 EST
Look at:
http://www.sendmail.org/~ca/email/cyrus/sysadmin.html

Have you tried using 'pwcheck_method:pam' ?
Comment 2 D. Wagner 2008-11-04 04:58:44 EST
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
pwcheck_method:pam

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
# sasldblistusers2 
#

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]]
# sasldblistusers2  
daw@senfl.cs.berkeley.edu: userPassword
#

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.
Comment 3 D. Wagner 2008-11-23 20:58:49 EST
Is there any further information I can provide to help troubleshoot this?
Comment 4 Fedora Admin XMLRPC Client 2009-05-04 04:27:33 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Bug Zapper 2009-06-09 23:09:21 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Bug Zapper 2009-07-14 10:13:01 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.