Bug 205173

Summary: mail/poppassd: change of password hangs and never returns
Product: Ports & Packages Reporter: Russell <fbsdbug>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Closed Feedback Timeout    
Severity: Affects Many People CC: miwi, tedm, tedm
Priority: --- Flags: bugzilla: maintainer-feedback? (tedm)
Version: Latest   
Hardware: amd64   
OS: Any   

Description Russell 2015-12-09 22:30:05 UTC 
The mail/poppassd port does not function on any 10.2 amd64 system that I have.

When testing, the following happens:

$ telnet localhost 106
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
200 poppassd v1.2 hello, who are you?
user someusername
200 your password please.
pass initialpassword
200 your new password please.
newpass newpassword

And then it just hangs there, never to return the expected "200 Password changed, thank-you."

If you check the processes, there is a root process running "passwd someusername", so I'm guessing something was changed in the way passwd is called or returns information which is breaking it.  The same binary works perfectly fine on a 9.2 system, but all passwd prompts seem to be the exact same from what I can tell.  It does return the expected error if you give it an incorrect initial password.  I did some testing on my own, but none of my diffs seemed to fix it so far.

Port is basically non-functional on 10.2 amd64 has been all of my testing.

-Russell
Comment 1 Russell 2015-12-11 21:22:37 UTC 
Have dug into this a bit more.  The problem seems to be related to the character returned when passwd exits after the user account password has been changed.  The code seems to be looking for the "\n" character to be returned (which it does in previous FreeBSD versions).  However, in 10.2 this seems to have been replaced with a "\0".  This same character is used to terminate the match arrays, so there is no way to match against the returned \0 without a bit of code changes.  We were able to make it work creating a placeholder value in P4, and then matching on that when the returned string from passwd was \0:

Added into P4:
"Code0",

Added above the "if (*str == 0) return *pat == 0 ? 2 : 1;" line in the match function:

   if (strcmp(pat,"Code0")==0){
     if (strcmp(str,"\0")==0){
       return 2;
     }
   }


I am not able to determine why passwd returns the \0 instead of \n.  The passwd.c is the same between versions, which tells me something else has changed, possibly in the functionality of termios?

Any assistance would be appreciated.

-Russell
Comment 2 tedm 2015-12-16 07:50:05 UTC 
I think this should be filed as a bug in passwd.c

passwd.c is supposed to be system and operating system specific.

While it may be that termios has changed, or something else in FreeBSD 10 has changed, the fact remains that passwd's output has changed - thus passwd needs to be modified so that it retains it's same behavior.
Comment 3 tedm 2016-01-29 02:13:48 UTC 
After looking at the code for passwd.c I am guessing the problem is that something was changed in pam_chauthtok() - the conversation callback is returning a \0 instead of a \n.  I have not looked into why it's doing this but clearly changing the behavior was done to fix something else - as /usr/bin/password is a command line user interface program I don't think the maintainers care how it looks to the users.  It might even be that this is caused by a stray \0 in the conversation since one change in the struct passwd definition in main is to set it to nulls.

My suggestion would be to either adopt your fix in poppassd, or make this change in passwd.c - add "fprintf(stderr, "\n");" after the pam_end() call and before the exit().  Currently I don't have a system built I can test this on, and it would result in an extra \n in the output which might break other stuff although I would guess that few password changing programs out there spawn a shell for /usr/bin/passwd like poppassd does.

The poppassd program should be rewritten to use pam - and it's output should be encrypted with SSL - and the client programs out there that use the protocol should be rewritten to use SSL.  This might be one of those sleeping dogs that we let lie.