[Exim] Some problems with PAM

Pàgina inicial
Delete this message
Reply to this message
Autor: J. Nick Koston
Data:  
A: exim-users
Assumpte: [Exim] Some problems with PAM
Auth for uucp suceeds with any pass. However if the password is NULL then we
get a segfault ??PAM's fault??.

\0uucp\0somepass
Exim version 3.11 debug level 9 uid=0 gid=0
Berkeley DB: Sleepycat Software: DB 2.4.14: (6/2/98)
Caller is an admin user
Caller is a trusted user
sender address = NULL
220 bd.darkorb.net ESMTP Exim 3.11 #1 Tue, 07 Dec 1999 19:11:04 -0500
220 bd.darkorb.net ESMTP Exim 3.11 #1 Tue, 07 Dec 1999 19:11:04 -0500
smtp_setup_msg entered
AUTH PLAIN AHV1Y3AAc29tZXBhc3M=
SMTP<< AUTH PLAIN AHV1Y3AAc29tZXBhc3M=
Running PAM authentication for user "uucp"
PAM error: Authentication service cannot retrieve authentication info.
fixed_plain authenticator:
$1 =
$2 = uucp
$3 = somepass
expanded string: yes
235 Authentication succeeded
235 Authentication succeeded

What really scares me (is this a PAM bug):
AUTH PLAIN \0uucp\0
Exim version 3.11 debug level 9 uid=0 gid=0
Berkeley DB: Sleepycat Software: DB 2.4.14: (6/2/98)
Caller is an admin user
Caller is a trusted user
sender address = NULL
220 bd.darkorb.net ESMTP Exim 3.11 #1 Tue, 07 Dec 1999 19:11:42 -0500
220 bd.darkorb.net ESMTP Exim 3.11 #1 Tue, 07 Dec 1999 19:11:42 -0500
smtp_setup_msg entered
AUTH PLAIN AHV1Y3AA
SMTP<< AUTH PLAIN AHV1Y3AA
Running PAM authentication for user "uucp"
Segmentation fault
<<<<<<<<<<<<<<<<<<<<<
Program received signal SIGSEGV, Segmentation fault.
0x807b09f in strcpy () at ../sysdeps/generic/strcpy.c:30
30    ../sysdeps/generic/strcpy.c: No such file or directory.
(gdb) back
#0  0x807b09f in strcpy () at ../sysdeps/generic/strcpy.c:30
#1  0x80a49a8 in _IO_stdin_used ()
#2  0x8090383 in strcpy () at ../sysdeps/generic/strcpy.c:30
#3  0x401b5564 in _init () from /lib/security/pam_pwdb.so
#4  0x401b64e7 in _init () from /lib/security/pam_pwdb.so
#5  0x401b6800 in _init () from /lib/security/pam_pwdb.so
#6  0x401b68a7 in pam_sm_authenticate () from /lib/security/pam_pwdb.so
#7  0x4005f748 in pam_fail_delay () from /lib/libpam.so.0
#8  0x4005fa05 in _pam_dispatch () from /lib/libpam.so.0
#9  0x400611ec in pam_authenticate () from /lib/libpam.so.0
#10 0x8090470 in strcpy () at ../sysdeps/generic/strcpy.c:30
#11 0x805f499 in strcpy () at ../sysdeps/generic/strcpy.c:30
#12 0x805ffbe in strcpy () at ../sysdeps/generic/strcpy.c:30
#13 0x8061960 in strcpy () at ../sysdeps/generic/strcpy.c:30
#14 0x8091769 in strcpy () at ../sysdeps/generic/strcpy.c:30
#15 0x8076a03 in strcpy () at ../sysdeps/generic/strcpy.c:30
#16 0x805dec7 in strcpy () at ../sysdeps/generic/strcpy.c:30
#17 0x400c91eb in __libc_start_main (main=0x80590cc <strcpy+59420>, argc=4, argv=0xbffffc84, 
    init=0x8049e80 <_init>, fini=0x8091d8c <_fini>, rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xbffffc7c)
    at ../sysdeps/generic/libc-start.c:90
(gdb) 
<<<<<<<<<<<<<<<<<



---from call_pam.c----
if (pam_error == PAM_USER_UNKNOWN ||
    pam_error == PAM_AUTH_ERR ||
    pam_error == PAM_ACCT_EXPIRED)
  return FAIL;
---------------------------


It seems that anything > 0 is a fatal error so if(pam_error > 0) makes more
sense to me unless there is something I am missing.

--- src/auths/call_pam.c.old    Tue Dec  7 19:15:55 1999
+++ src/auths/call_pam.c        Tue Dec  7 19:16:09 1999
@@ -166,9 +166,7 @@
 *errptr = (char *)pam_strerror(pamh, pam_error);
 DEBUG(9) debug_printf("PAM error: %s\n", *errptr);


-if (pam_error == PAM_USER_UNKNOWN ||
-    pam_error == PAM_AUTH_ERR ||
-    pam_error == PAM_ACCT_EXPIRED)
+if (pam_error > PAM_SUCCESS)
   return FAIL;


return ERROR;

-- 
        Nick



-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDeipvQRBACXRQJi5PCuUa5fYfEMc/LvfbSc3oHghiAn5slOAEdOaHltHTuX
nu01FIY/O29sbu1PGqa6hWsaiv8jbUuY/e5YXDGkveA26EX078aqfcomOGWCoY38
8dWgLFd9w/5A+OAi9M4DlSgDguRj3VpXwbS2/YaqmToaVXZxX0eS4TzA6wCg5fBW
j30TqUAfZZ5uZ1MGO63wLS8D/2BfJ5IJFoKqKZ1Mr74M0I+IsBvSDfg/9Zp+8iqW
5TnLI9HFfdouCp6Dd1ohKLjJXTwQV34nC4uWR8DKSQYxZsoTt25wg7q+cb5pqSFM
j7D10e9rWMP2cjFVVV0sLGXFbShtNRQ/cmrPSqNI1/sucyjeuTdgaiuRg/2gXM+R
SrbdBACREZYLW/3RlNrESLd2RFvuPNkiCI2Sta5oeQwnL6dRzX8hX8WuOHqU8NES
vGTR9NSkIzzM/9+K539J2Drgtn7QUkz/0FiJejxTmHlu9PoeaKs38mktjJ1T1Bi2
ba+njNmkIiYidlBqli0rT3DeXU9IGFoBMQmLRJ04P7ZS9y4JUbQvSi4gTmljayBL
b3N0b24gKEJsdWVEcmFjbykgPGJkcmFjb0BkYXJrb3JiLm5ldD6IVQQTEQIAFQUC
N6Km9AMLCgMDFQMCAxYCAQIXgAAKCRCUleWDU9+v9ZXCAKCabKfJOi2/q2uPsyz/
jK6y6Df6IwCePitKxAg8g79xE3tkFNJroOYdgBiIRgQQEQIABgUCN6KvewAKCRDN
mLlpIWwdg1mJAJsEznPV3aq6THz0sX4Csr0l9iLgpwCfYihf+FhoIl/hDBfSaEvM
OoYzDHy5Ag0EN6KndRAIAM+zDGxzWFH5itH8EDNabOiBOOHWB/y+A76eAErY6E41
nO/0j3gpGr1WfyFW5VRKiElD0+eDBR9bpg7jdrtjdtQiGiDQWsdFHmQQUKU1aIH8
zlyr2fTJveyqZde9eSGiu6Sm9EmO8wBTJhCO4Myq68gyQDBjmzr4qX+EMy1HuYKG
QmHvP/YkwfRew5umqrGttu6+ia/AfNzB+SqpYKjv3AE4Aie/BAOugLYT3XaYmg31
bS7b6yYRegGmkhPyTECZ5MoBfG38S6kpVmxHqsozqEBD9GTCRcwXsn/b0CV11nA+
B8MnUvHzUicS9Wv9VLkcNDTAynbzPvx1X3q6DDOYuKMAAwYH/1ud8ye6cgMNuE+Y
k9MhjgE60vMCt6iP0+qoGVMcxgvbD5k1z1U3LE61nhhK4jpx4zL7tRbsNJGrxOtS
NTAU59UHf+3E/ZecHh2PXrX1achBP7jaXjJ/aE+JTKA8Y48mSC7ZaasVwi/pV3gS
y+ptvo8W8lvJREh0YAdPSuGVjyOQ20xENMFxJvuyfGqUHj4RJiNHs3ybkp5NeVo/
KvGKH38now/R0IgFpmh/Ubl50caMF7/SpHbY3N83GP6xAZa8O8L48vFhzG7rkxg9
SkGztoxcukeCsb7TxDhHrX3h9NoyOtjiTZS3oN4jULK9aqtm04RPhkbppfIG/6ac
MYjVJACIRgQYEQIABgUCN6KndQAKCRCUleWDU9+v9UvNAJ9D3tvLHsghuyeRT4Fs
vJFeHqT86gCdHJx+XXlyLPrNG0ZrB44Q6+a87iw=
=Flor
-----END PGP PUBLIC KEY BLOCK-----