postfix sasl2 pam_mysql on Debian Sarge
Nicolas
nicolas at skypro.be
Tue Mar 13 19:10:06 EST 2007
>>
>> PARAMS="-m /var/spool/postfix/var/run/saslauthd -r"
>>
>
> You are planning to run Postfix chrooted, right?
>
>
That's not an issue for me as long as it's not involving any non-trivial
security problems.
>From http://www.postfix.org/security.html:
"Although chroot(2), even when combined with low privilege, is no
guarantee against system compromise it does add a considerable hurdle.
And we all know that every little bit helps."
>From Wietse Venema himself:
"Don't turn on Postfix chroot unless you must, and certainly don't turn
it on until you have Postfix working. Postfix as distributed by myself
has chroot turned off by default."
I'd rather follow Wietse's advice :)
>
>> I also pasted the result of saslfinger below, for not burrying my second
>> question. So my first question is: how come the pid file is not in
>> /var/spool/postfix/var/run/saslauthd?
>>
>
> I don't know. I didn't know it was possible to tell saslauthd it should put
> the socket in a special directory at all. All I know is: The socket directory
> (run_path) is where saslauthd puts everything.
>
>
>
Found the answer if anyone is interested. See
http://wiki.ev-15.com/debian:mail_system
>>
>> igloo:/etc/postfix# tail /var/log/auth.log
>>
>> Mar 12 16:43:52 igloo saslauthd[4670]: rel_accept_lock : released accept
>> lock
>> Mar 12 16:43:52 igloo saslauthd[4666]: get_accept_lock : acquired accept
>> lock
>> Mar 12 16:43:52 igloo saslauthd[4670]: DEBUG: auth_pam: pam_authenticate
>> failed: Authentication failure
>> Mar 12 16:43:52 igloo saslauthd[4670]: do_auth : auth failure:
>> [user=email at address] [service=smtp] [realm=] [mech=pam] [reason=PAM auth
>> error]
>>
>
> PAM has a problem. My guess (!) is, its with the pam_mysql settings you've
> given.
>
>
Yes, you helped me hit the bug here. Relevant stuff in the pam_mysql README:
verbose (0)
If set to 1, produces logs with detailed messages that describes what
PAM-MySQL is doing. May be useful for debugging.
crypt (plain)
The method to encrypt the user's password:
0 (or "plain") = No encryption. Passwords stored in plaintext.
HIGHLY DISCOURAGED.
1 (or "Y") = Use crypt(3) function.
2 (or "mysql") = Use MySQL PASSWORD() function. It is possible
that the encryption function used by PAM-MySQL
is different from that of the MySQL server, as
PAM-MySQL uses the function defined in MySQL's
C-client API instead of using PASSWORD() SQL
function
in the query.
3 (or "md5") = Use plain hex MD5
So I modified /etc/pam.d/smtp to use verbose=1 and, finally, crypt=2,
since this seemed to be the problem.
auth required pam_mysql.so user=<user at address> passwd=<pass>
host=127.0.0.1 db=mail table=postfix_users usercolumn=email
passwdcolumn=clear crypt=2 verbose=1
account sufficient pam_mysql.so user=<user at address> passwd=<pass>
host=127.0.0.1 db=mail table=postfix_users usercolumn=email
passwdcolumn=clear crypt=2 verbose=1
>
> Get Postfix out of the way to simplify your debug setup. Start saslauthd from
> commandline with the settings you want to gave in /etc/default/saslauthd AND
> add "-d" to keep saslauthd attached to the screen in debug mode.
>
>
So that would be
# /usr/sbin/saslauthd -d -a pam &
[1] 3654
saslauthd[3654] :main : num_procs : 5
igloo:/home/nicolas# saslauthd[3654] :main : mech_option: NULL
saslauthd[3654] :main : run_path : /var/run/saslauthd
saslauthd[3654] :main : auth_mech : pam
saslauthd[3654] :ipc_init : using accept lock file:
/var/run/saslauthd/mux.accept
saslauthd[3654] :detach_tty : master pid is: 0
saslauthd[3654] :ipc_init : listening on socket:
/var/run/saslauthd/mux
saslauthd[3654] :main : using process model
saslauthd[3655] :get_accept_lock : acquired accept lock
saslauthd[3654] :have_baby : forked child: 3655
saslauthd[3654] :have_baby : forked child: 3656
saslauthd[3654] :have_baby : forked child: 3657
saslauthd[3654] :have_baby : forked child: 3658
> Then use testsaslauthd with at least the following options:
>
> $ testsaslauthd -f /var/spool/postfix/var/run/saslauthd -r -s smtp -u <user> -p <pass>
>
... and there you go
# testsaslauthd -s smtp -u <user at address> -p <pass>
saslauthd[3756] :rel_accept_lock : released accept lock
saslauthd[3757] :get_accept_lock : acquired accept lock
saslauthd[3756] :do_auth : auth success: [user=<user at address>]
[service=smtp] [realm=] [mech=pam]
saslauthd[3756] :do_request : response: OK
0: OK "Success."
Interestingly, when specifying either -f
/var/spool/postfix/var/run/saslauthd or -f /var/spool/saslauthd I get this:
# testsaslauthd -f /var/spool/postfix/var/run/saslauthd -r -s smtp -u
<user at address> -p <pass>
connect() : Connection refused
# testsaslauthd -f /var/run/saslauthd -r -s smtp -u <user at address> -p
<pass>
connect() : Connection refused
>> -- content of /etc/postfix/sasl/smtpd.conf --
>> pwcheck_method: saslauthd
>> mech_list: plain login
>> allow_plaintext: true
>> auxprop_plugin: sql
>> sql_hostnames: 127.0.0.1
>> sql_user: --- replaced ---
>> sql_passwd: --- replaced ---
>> sql_database: mail
>> sql_select: select password from users where email = '%u'
>> #saslauthd_path: /var/run/saslauthd
>>
>
>
> This /etc/postfix/sasl/smtpd.conf won't work. Either you use saslauthd and
> PAM with encrypted passwords or you use the auxprop sql plugin without crypted
> passwords.
>
> If you go for saslauthd do this:
>
> /etc/postfix/sasl/smtpd.conf
> pwcheck_method: saslauthd
> mech_list: plain login
>
Blindly copied the above. Now that you mention it, it couldn't be more
obvious. I could indeed also work with the auxprop sql plugin after
modifying the /etc/postfix/sasl/smtpd.conf (had to change the sql_select
line too, sasl parses the username "email at address" into "user"@"realm",
so I needed to define it as '%u@%r' ).
Anyway, I think that saslauthd/pam offers more security, so I removed
Postfix out of the chroot jail, added user postfix to sasl group and
adapted /etc/postfix/sasl/smtpd.conf for saslauthd. I am yet left with
one last obstable: when called through Postfix, saslauthd parses the
user <email at address> into <email> and <address>, and assigns <address>
to "realm" instead of to "user".
Mar 14 00:14:49 igloo saslauthd[4308]: pam_mysql -
pam_mysql_release_ctx() called.
Mar 14 00:14:49 igloo saslauthd[4308]: pam_mysql -
pam_mysql_destroy_ctx() called.
Mar 14 00:14:49 igloo saslauthd[4308]: pam_mysql - pam_mysql_close_db()
called.
Mar 14 00:14:49 igloo saslauthd[4308]: do_auth : auth failure:
[user=<email>] [service=smtp] [realm=<address>] [mech=pam] [reason=PAM
auth error]
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - option verbose is set
to "1"
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - pam_mysql_close_db()
called.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - pam_sm_authenticate()
called.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - pam_mysql_converse()
called.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - pam_mysql_open_db()
called.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - pam_mysql_open_db()
returning 0.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql -
pam_mysql_check_passwd() called.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql -
pam_mysql_format_string() called
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql -
pam_mysql_quick_escape() called.
Mar 14 00:14:49 igloo last message repeated 3 times
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - SELECT clear FROM
postfix_users WHERE email = '<email>'
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - SELECT returned no
result.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql -
pam_mysql_check_passwd() returning 1.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - pam_sm_authenticate()
returning 10.
Mar 14 00:14:49 igloo saslauthd[4309]: DEBUG: auth_pam: pam_authenticate
failed: User not known to the underlying authentication module
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql -
pam_mysql_release_ctx() called.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql -
pam_mysql_destroy_ctx() called.
Mar 14 00:14:49 igloo saslauthd[4309]: pam_mysql - pam_mysql_close_db()
called.
Mar 14 00:14:49 igloo saslauthd[4309]: do_auth : auth failure:
[user=<email>] [service=smtp] [realm=<address>] [mech=pam] [reason=PAM
auth error]
I changed /etc/default/saslauthd to
START=yes
PARAMS="-r"
MECHANISMS="pam"
...and /etc/init.d/saslauthd to
PIDFILE="/var/run/${NAME}/saslauthd.pid"
... but these did not help.
I had the impression that the deamon does read /etc/default/saslauthd,
but disregards the PARAMS= line:
root 4350 0.0 1.0 7196 2052 ? Ss 00:37 0:00
/usr/sbin/saslauthd -a pam
root 4351 0.0 1.0 7196 2052 ? S 00:37 0:00
/usr/sbin/saslauthd -a pam
root 4352 0.0 1.0 7196 2052 ? S 00:37 0:00
/usr/sbin/saslauthd -a pam
root 4353 0.0 1.0 7196 2052 ? S 00:37 0:00
/usr/sbin/saslauthd -a pam
root 4354 0.0 1.0 7196 2052 ? S 00:37 0:00
/usr/sbin/saslauthd -a pam
This seems to be correct, following the clues I found on
http://www.nervous.it/txt/Postfix-SMTP-AUTH-4-DUMMIES.html - I concur ^^
- I added the "-r" to the /etc/init.d/saslauthd instead, on my system it
looks like this:
DAEMON_ARGS="$DAEMON_ARGS -a $MECHANISMS -r $MECH_OPTIONS $OPTIONS
$THREAD_OPTIONS"
Restart saslauthd and voilà! it works.
So now that I acquired boundless knowledge I can go write a tutorial
myself! :-)
Thanks,
Nicolas
More information about the Cyrus-sasl
mailing list