Description of problem: While working on bug 679848, we discovered a new problem: Running yppasswdd with the -x option to pass data to an external program to update the source files and maps may insert garbage characters in front of the username. It's supposed to pass the data to the external program on stdin in the format username o:oldpassword p:newpassword s:shell g:gecos\n In my testing, 'homer' sometimes comes into the external program as 'pauhomer' or other garbage prefixed to homer. Looking at the source, I see it doesn't clear memory after malloc; from ypserv-2.19/rpc.yppasswdd/update.c: 873 if ((parentmsg = malloc (msglen)) == NULL) 874 { 875 log_msg ("rpc.yppasswdd: out of memory"); 876 return res; 877 } 878 879 strcat (parentmsg, yppw->newpw.pw_name); Inserting a memset() call before line 879 fixes the problem. Version-Release number of selected component (if applicable): ypserv-2.19-5 How reproducible: almost always Steps to Reproduce: 1. modify /etc/sysconfig/yppasswdd and set YPPASSWDD_ARGS="-x /usr/lib/yp/external-test" 2. create /usr/lib/yp/external-test with contents ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #!/usr/bin/perl $data = <>; open DEBUG, ">/tmp/external-test.log"; print DEBUG "$data"; close DEBUG; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3. service rpc.yppasswd start 4. on a NIS client, run yppasswd to change homer's password 5. watch /tmp/external-test.log on the NIS server Actual results: pauhomer o:password p:5FsD7UxMQ5mnU Expected results: homer o:password p:5FsD7UxMQ5mnU Additional info:
Created attachment 481969 [details] patch to fix username garbage
I see there's actually a ypserv-2.24 upstream ftp://ftp.kernel.org/pub/linux/utils/net/NIS/ypserv-2.24.tar.bz2 But the website still indicates 2.23 is the newest: http://linux-nis.org/nis/ypserv/index.html 2.24 fixes this by changing the strcat on line 879 to a strcpy: - strcat (parentmsg, yppw->newpw.pw_name); + strcpy (parentmsg, yppw->newpw.pw_name); It fixes a few other bugs with external_update_pipe() also.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0205.html