Non-root users cannot change samba passwords if "unix password sync" is set to "yes" in smb.conf : > $ smbpasswd > Old SMB password: > New SMB password: > Retype new SMB password: > SAMR connection to machine NT_STATUS_ACCESS_DENIED failed. Error was > 127.0.0.1, but LANMAN password changed are disabled The system passwd program comes from the shadow-4.0.7 package, and the chat sequence (run as root) is : > # passwd user1 > Changing password for user1 > Enter the new password (minimum of 5, maximum of 127 characters) > Please use a combination of upper and lower case letters and numbers. > New password: > Re-enter new password: > Password changed. This problem also happens with samba-3.3.
Created attachment 4606 [details] smb.conf
Created attachment 4607 [details] level 10 log for smbpasswd failure
Looks like the conversation with the child program /usr/bn/passwd aborts and we get an error reading from the pipe. What system (distribution/kernel) are you running this on ?
My system is a LFS (Linux From Scratch) installation, with regular update/upgrade of packages. Currently it is running 2.6.30.2 kernel, with glibc 2.10.1 (but the problem also happens with glibc 2.5.1). I think so it should be a problem with /usr/bin/passwd chatting. However passwd is working well, but I don't know how samba calls passwd. On the other hand, root can change samba passwords with system passwords synchronized. Is it possible that the problem is with permissions ?
Please set "debug level = 100" and "passwd chat debug = yes". Then you will see the complete dialogue in the logfile including the passwords. Maybe that gives a hint. Volker
Created attachment 4614 [details] level 100 log for smbpasswd failure
I've generated a level 100 log with "passwd chat debug = yes", but I don't see the passwords I've entered : > [2009/08/31 09:00:27, 3] smbd/chgpasswd.c:472(chat_with_program) > chat_with_program: Dochild for user user1 (uid=0,gid=0) (as_root = Yes) > [2009/08/31 09:00:27, 10] smbd/chgpasswd.c:231(dochild) > Invoking '/usr/bin/passwd user1' as password change program. > [2009/08/31 09:00:27, 0] lib/util_sock.c:612(read_socket_with_timeout) > read_socket_with_timeout: timeout read. read error = Socket operation on > non-socket. > [2009/08/31 09:00:27, 100] smbd/chgpasswd.c:301(expect) > expect: expected [*new*password*] received [] match no > [2009/08/31 09:00:27, 2] smbd/chgpasswd.c:307(expect) > expect: NT_STATUS_ACCESS_DENIED > [2009/08/31 09:00:27, 3] smbd/chgpasswd.c:342(talktochild) > Response 1 incorrect > [2009/08/31 09:00:27, 3] smbd/chgpasswd.c:414(chat_with_program) > chat_with_program: Child failed to change password: user1 However, it says something about "socket operation" which causes the failure. What "sockets" are used by samba in calling passwd ?
Next step diagnosing this: Connect to a server with Windows. Find to appropriate smbd that serves your workstation with smbstatus. Start strace -p <smbd-pid> -f -ttT -o /tmp/smbd.strace Then change your password. Stop strace. Please upload the file /tmp/smbd.strace. Thanks, Volker
Created attachment 4618 [details] strace output
I've generated the strace output accordingly, but it does not seem to contain anything useful. 1. On a WinXP computer, I created a local user "user1", which coincides with the account on the samba server. 2. Logon to Windows as "user1". 3. Invoke "control panel" -> "user accounts", then click "manage my network passwords" on the left column, and add the information "Server: x093", "User name: user1@x093" and the password. 4. Connect to samba server with "net use f: \\x093\tmp" 5. Start strace on the samba server. 6. Change the password as in step 3 above. 7. Stop strace on the samba server. As we have never attempted to change samba/unix passwords using Windows, I am not sure if the above steps are correct or not.
After each smbpasswd failure, many samba-related files are left in /tmp : SMBclose.1.req SMBsesssetupX.1.req SMBtrans.2.req in_\samr_56.1.prs SMBclose.2.req SMBsesssetupX.2.req SMBtrans.3.req in_\samr_56.2.prs SMBnegprot.1.req SMBsesssetupX.3.req SMBtrans.4.req out_\samr_55.1.prs SMBnegprot.2.req SMBsesssetupX.4.req SMBulogoffX.1.req out_\samr_55.2.prs SMBnegprot.3.req SMBsesssetupX.5.req SMBwriteX.1.req out_\samr_56.1.prs SMBntcreateX.1.req SMBsesssetupX.6.req SMBwriteX.2.req out_\samr_56.2.prs SMBntcreateX.2.req SMBtconX.1.req SMBwriteX.3.req SMBreadX.1.req SMBtdis.1.req in_\samr_55.1.prs SMBreadX.2.req SMBtrans.1.req in_\samr_55.2.prs
I'm closing this bug as invalid. Let's clarify how to change passwords from Windows against a Samba server on the samba@samba.org mailing list first. Alternatively you might want to look into your Windows documentation how to use the Ctrl-Alt-Del dialogue. Volker
Created attachment 4627 [details] strace output (compress due to large size)
I have generated the appropriate strace output. The Windows error message reads "You do not have permission to change your password".
The strace clearly shows in line 29182 that the password program prints "Changing password for user1". In line 29192 it prints "Enter the new password (minimum o ..." (this is cut off). You need to add those lines to the passwd chat dialogue. I'm sorry, but setting up the passwd chat always is a pretty tricky business. It is similar to the good old ppp chat talking to a modem for internet access. There is not really much we can do about that. Closing this bug as invalid, this is a configuration issue first. Thanks, Volker
Created attachment 4630 [details] strace output (part 1)
Created attachment 4631 [details] strace output (part 2)
Created attachment 4632 [details] strace output (part 3)
Created attachment 4642 [details] working smb.conf
Created attachment 4643 [details] level 100 log for smbpasswd 3.2.6 (sucessful)
Created attachment 4644 [details] level 100 log for smbpasswd 3.4.0 (failed)
I'm sorry but I don't think I'm pointless in insisting that this is a VALID bug. I repeated the tests with samba-3.2.6 and found that it works! I can see the clear text passwords as described in Comment #5 above (lines 3673-3706 of attachment 4643 [details]). Although changing password from Windows still fails, I don't care as long as smbpasswd works. In comparing the logs, the problem may probably be with "lib/util_sock.c" (see lines 4128-4129 of attachment 4644 [details]).
Ok, if the same config worked with 3.2 we have a bug. Sorry for closing it. Volker
My proposed fix : The lines 522 and 591 of lib/util_sock.c originally read "readret = sys_recv(fd, buf+nread, maxcnt-nread, 0);" I changed these two lines to "readret = sys_read(fd, buf+nread, maxcnt-nread);" which is copied from samba-3.2.6, and re-compiled, and it worked! I don't actually know whether this is a correct fix, please comment.
Oh interesting, looks like recv() fails with a pty: read_socket_with_timeout: timeout read. read error = Socket operation on non-socket. We need to add an equivalent of read_socket_with_timeout to use sys_read() instead (or just change read_socket_with_timeout back to using sys_read instead of sys_recv with 0 flags). Marking this as blocker as I should be able to get this fixed and tested for 3.4.1 (due Friday 11th Sept). Jeremy.
Created attachment 4653 [details] Fix for master (and 3.4.1). Fix for master and 3.4.1. Changes read_socket_with_timeout() to read_fd_with_timeout() and adds comments to make this clear. Jeremy.
Created attachment 4654 [details] (Finished) fix for master and 3.4.1. Fixes all places read_socket_with_timeout() was changed to read_fd_with_timeout() :-). Jeremy.
Created attachment 4655 [details] Fix for 3.4.1 Fix for master has been applied. This fix applies to 3.4.1. Volker please review then assign to Karolin for inclusion in 3.4.1. Commit log message is : Fix bug 6673 - smbpasswd does not work with "unix password sync = yes". Revert change from 3.3 -> 3.4 with read_socket_with_timeout changed from sys_read() to sys_recv(). read_socket_with_timeout() is called with non-fd's (with a pty in chgpasswd.c and with a disk file in lib/dbwrap_file.c via read_data()). recv works for the disk file, but not the pty. Change the name of read_socket_with_timeout() to read_fd_with_timeout() to make this clear (and add comments). Jeremy. NB. This patch conflicts with Simo's fix for bug #6693, due to the rename of the function. If you want I can add a git format patch that layers on top of Simo's fix. Let me know. Jeremy.
(In reply to comment #28) > NB. This patch conflicts with Simo's fix for bug #6693, due to the rename of > the function. If you want I can add a git format patch that layers on top of > Simo's fix. Let me know. My patch has been pushed to master, so it may be a good idea to rebase on top.
It's not master that's the problem (the patch is already in there), it's which patch is pushed to 3.4.1 first that is the issue. Jeremy.
When trying to apply this patch on top of d5098d7372fb3ab (v3-4-test as of just now) I get: vlendec@delphin:~/git/v3-4-test$ patch -p1 </tmp/look patching file source3/include/proto.h Hunk #1 succeeded at 1373 (offset -10 lines). patching file source3/lib/util_sock.c Hunk #1 succeeded at 490 (offset -48 lines). Hunk #2 succeeded at 521 (offset -49 lines). Hunk #3 FAILED at 534. Hunk #4 FAILED at 573. Hunk #5 succeeded at 585 (offset -51 lines). Hunk #6 FAILED at 605. Hunk #7 succeeded at 628 (offset -52 lines). Hunk #8 succeeded at 711 (offset -52 lines). Hunk #9 succeeded at 773 (offset -52 lines). Hunk #10 succeeded at 854 (offset -52 lines). 3 out of 10 hunks FAILED -- saving rejects to file source3/lib/util_sock.c.rej patching file source3/libsmb/clientgen.c Hunk #1 succeeded at 218 (offset -78 lines). patching file source3/smbd/chgpasswd.c Hunk #1 succeeded at 268 (offset -1 lines). patching file source3/smbd/process.c Hunk #1 succeeded at 127 (offset -1 lines). Hunk #2 succeeded at 161 (offset -1 lines). Would it be possible that you upload the patch as the output of "git format-patch", rebased on top of current 3-4-test? Thanks, Volker
Created attachment 4664 [details] git-am format patch for 3.4.1.
Comment on attachment 4664 [details] git-am format patch for 3.4.1. Looks good, thanks. Volker
Karolin, please include this for the next 3.4 release. Thanks, Volker
Pushed, will be included in 3.4.1. Closing out bug report. Thanks!