Date: Fri, 29 Jan 2016 02:13:48 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 205173] mail/poppassd: change of password hangs and never returns Message-ID: <bug-205173-13-JdFjRogXUc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-205173-13@https.bugs.freebsd.org/bugzilla/> References: <bug-205173-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205173 --- Comment #3 from tedm@ipinc.net --- 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 pas= swd 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 o= n, and it would result in an extra \n in the output which might break other st= uff 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 shoul= d 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 t= hat we let lie. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-205173-13-JdFjRogXUc>