* Solar Designer <solar@private> [2006-07-03 04:38:07 +0400]: > > I suppose the passwd > > program would make sure the two entered passwords are identical and then > > hand that password off to pam_tcb). > > That's not how things work. > > The PAM conversation function provided by the passwd program receives > multiple echo-off input prompts from the PAM stack. It does not know > which of those prompts are for the new password, nor does it care. In > fact, for a text terminal interface, the passwd program may provide the > standard PAM conversation function from libpam_misc rather than bother > with its own implementation. Ok, I think I'm understanding that now. > With the configuration you had posted, the two new password prompts > originate from pam_passwdqc. If you remove pam_passwdqc from the stack > and also remove the use_authtok option from pam_tcb, then the prompts > will originate from pam_tcb. Ahhh... ok. > As it relates to the segfault you're seeing, I think it'd be most > straightforward to debug it rather than proceed to theorize as to its > possible cause. I agree. And I'm starting to suspect some misfiring in glibc and crypt_blowfish. I've been monkeying around and I'm suspecting that crypt_blowfish is not properly integrated (which seems odd because all my glibc patchs are owl-derived, but I may have goofed something in the application or whatever). At any rate, I've been fiddling with the options of pam_tcb and tried to make it use regular md5 passwords by first changing "prefix=$2a$" to "prefix=$1$", which didn't work. I then tried removing the prefix option and using "md5" in there, but now I'm seeing this in syslog: authpriv.crit: passwd[2046]: pam_tcb(passwd:chauthtok): crypt_gensalt_ra: Invalid argument And I get authentication failures on trying even provide my user password (passwd dies with "passwd: Memory buffer error.", using the ALT passwd program). So I tried using the "plain_crypt" option and I get the same thing. In fact, the *only* way I can make pam_tcb authenticate me is with having the default "prefix=$2a$", or omitting it altogether (and not using plain_crypt or md5 either). Ok, now I'm not a C programmer, so I had to google for a sample piece of code to use the crypt functions, particularly so I could see what, if anything, was being returned for blowfish. I found this bit of code: #include <cstdlib> #include <iostream> #include <crypt.h> using namespace std; //compile: g++ hasher.cpp -o hasher -lcrypt int main(int argc, char** argv){ if (argc!=3) { cout << "Usage: $hasher <password> <salt>" << endl; return 1; } cout << crypt(argv[1], argv[2]) << endl; return 0; } [vdanen@build SOURCES]$ ./hasher foo '$1$salt' $1$salt$nWwtt7njwVig74jTAfjuG/ [vdanen@build SOURCES]$ ./hasher foo '$2a$salt' *0 [vdanen@build SOURCES]$ ./hasher foo '$2a$' *0 Now that doesn't look right to me (I wasn't sure if the blowfish needed a salt or not so I tried both). It could be that my blowfish invocation is wrong here too, which is why I'm getting the return I am; I've done some poking around but can't find anything that gives me what an example blowfish password should look like. Well, I did find this: http://www.openwall.com/lists/john-users/2005/07/02/1 and then tried hasher with '$2a$05' to try to simulate what I saw there and still no dice, so I think something is messed up with my glibc+crypt_blowfish integration. Now, if pam_tcb is returning this "*0" (or receiving it when it's trying to bcrypt what I type in), could that be causing the segfault? Or was this a bad code example to try to track the problem down? I don't mean to sound like an idiot, and I hope I'm not coming across as one, but encryption and C aren't my strong points... =) So I'm trying to do as much research/debugging as my limited skills in this area permit, but this is the conclusion I'm coming to. Am I way off base here? Or would a mis-application of crypt_blowfish be causing this (and the other symptoms of pam_tcb not working properly with those other options like "md5" and the like?). Could it just be that pam_tcb is unable to properly use the appropriate libcrypt functions? I'm going to keep fiddling with this and re-compare my glibc spec to the owl spec and also upgrade to 1.0.2 and see if I can come up with something that works. What I'd like to know is if that hasher program will actually output blowfish passwords like I think it should. I know SUSE also has crypt_blowfish support so maybe I'll try compiling that hasher program on my vmware install and see if it works properly. Thanks, and sorry for the long message (kinda writing and testing things at the same time). -- {FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4} mysql> SELECT * FROM users WHERE clue > 0; Empty set (0.00sec) :: Annvix - Secure Linux Server: http://annvix.org/ ::
This archive was generated by hypermail 2.1.3 : Sun Jul 02 2006 - 20:53:42 PDT