This bug was created by Jan Engelhardt <jengelh@linux01.gwdg.de> at the SuSE bugzilla. As I don't care about plain passwords I feed it to Samba.org. The original report from Jan: The smbd refuses a (plaintext) password whose 9'th, 10'th, etc. characters are uppersize. (Now read reproduction) Cause: In [samba-3.0.4-1.14, or any minor updates] samba-3.0.4/source/auth/pass_check.c, around line 446 in function string_combinations2() near: #ifdef PASSWORD_LENGTH len = MIN(len, PASSWORD_LENGTH); #endif the following is happening (upon initial entrance to the function): s = "nohohzuiW" offset = 0 fn = ... <I don't care> N = 9 PASSWORD_LENGTH is #defined to be 8 (found out by gdb) Thus, len is set to 8 -- and thus only the first eight characters are probed for upper-/lowercase, 9'th, 10'th and so on always stay lower case. A workaround is to remove the offending three lines, though that might impact speed, as the Samba developers tell us in include/includes.h:948 near /* what is the longest significant password available on your system? Knowing this speeds up password searches a lot */ #ifndef PASSWORD_LENGTH #define PASSWORD_LENGTH 8 #endif Guess what... 8 chars was for DES, but MD5 and Blowfish support more. I did not want to raise PASSWORD_LENGTH because in fact PASSWORD_LENGTH is (IMO) useless -- the string length is anyway calculated in string_combinations2(), and if PASSWORD_LENGTH is greater than the length of my password (it must be, otherwise MD5/BF don't work), there is no use in the call to [using the macro] MIN(). How to reproduce: Add a new user to the Shadow subsystem (i.e. /etc/passwd, /etc/shadow), giving him a password like "nohohzuiW". In smb.conf, encrypt passwords = no, update encrypted = no, min password length = 8 The client machine should preferably be Windows 95/98/98SE. And I really mean Windows, because that's the only one sending plaintext password in all-uppercase. smbclient works fine with this password.
Jan: Please retest with the current Samba version. This bug might be fixed with svn checkin 5290 to fix bug #2323. You find current, 3.0.14a packages for SuSE Linux products at ftp://ftp.SuSE.com/pub/projects/samba/ or http://download.Samba.org/samba/ftp/Binary_Packages/SuSE/ *** This bug has been marked as a duplicate of 2323 ***
svn #5290 (said fix) is already in 3.0.13-1(suse.i586.rpm). As for 3.0.14a, do you have a source tree, or a diff from 3.0.13-1 to said 3.0.14a? Thanks.
All packages are using the Samba.org 3.0.14a tar ball. And Samba.org also provides diffs from the previous to the next version. See http://download.Samba.org/samba/ftp/patch-3.0.13-3.0.14a.diffs.gz But I might have missunderstood you.
>All packages are using the Samba.org 3.0.14a tar ball. And Samba.org also provides diffs from the previous to the next version. If the samba-3.0.13-1.i586.rpm from SUSE 9.3 is a 3.0.14a, then: - svn #5290 is already applied - password authentication still fails I doubt that it has to be addressed in sesssetup.c, because it's an auth issue of strings_compare2() <auth/pass_check.c>.
The Samba version inside the SuSE RPMs named 3.0.13 is a Samba.org 3.0.13. Nothing else. My comment #3 was with regard to the packages available at ftp.SuSE.com or download.Samba.org atm. Bug #2323 was fixed with Samba 3.0.11. Therfore I expect this bug will stay in 3.0.14a. But please test it and reopen this bug if it still exits with 3.0.14a. Unfortunately I don't have a Windows 9x at my home test network.
Can you provide a diff -u between suse's 3.0.13-1 and your 3.0.14a? (Don't want to download 14+ megs, slow link) Thanks.
Please reopen. The bug persists in 3.0.14A.
this actually was not a duplicate of bug 2323. Reopening and assigning to myself.
ping
Created attachment 2262 [details] Fix Please consider inclusion.
this doesn't seem to be a problem any more. however due to missing test in bug 9705 we unfortunately have non-working plaintext auth since a long time. But anyway I'll close this one here as fixed now.