I have a YP (NIS) setup with one master server and several slave servers. One of the latter is in ypservers (together with the master server, as setup by ypinit -m). If I modify a YP-relevant file on the master server and do a 'make' in /var/yp, yppush fails with a segmentation violation (signal 11) and dumps core. This aborts 'make', thereby not processing the remaining maps. If I manually ypxfr a map from the master to any of the slave servers (invoked at the respective slave server as "ypxfr -h <master server> <map name>"), ypxfr fails with a segmentation violation (signal 11) and dumps core. It leaves a zero-sized file in /var/yp/<domainname> with a .nnnn suffix, e.g., rpc.byname.4631. None of this happened with 10.3. Btw, the only maps which can be successfully transferred are empty ones, i.e., containing no entries. The associated file in /var/yp/<domainname> has a size of 40960 bytes. One more note: this started to happen several months ago on 11-current compiled for armv6. At that time I thought it was just a problem on that architecture. But now, after installing 11.0 on all my machines, it happens on all of them (amd64 and i386).
Could you obtain backtraces from the ypxfr and yppush cores and paste them in this PR?
[0]# gdb /usr/libexec/ypxfr ypxfr.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `ypxfr'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/librpcsvc.so.5...Reading symbols from /usr/lib/debug//usr/lib/librpcsvc.so.5.debug...done. done. Loaded symbols for /usr/lib/librpcsvc.so.5 Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000000000000 in ?? () (gdb) where #0 0x0000000000000000 in ?? () #1 0x0000000800afe4ed in xdr_ypresp_all_seq (xdrs=<value optimized out>, objp=0x7fffffffd210) at /.../hal/z/SRC/FreeBSD/releng/11.0/lib/libc/yp/xdryp.c:105 #2 0x0000000800b11536 in clnt_vc_call (cl=<value optimized out>, proc=8, xdr_args=0x40178c <xdr_ypreq_nokey@plt>, args_ptr=0x7fffffffd218, xdr_results=0x4017cc <xdr_ypresp_all_seq@plt>, results_ptr=<value optimized out>, timeout={tv_sec = 10, tv_usec = 0}) at /.../hal/z/SRC/FreeBSD/releng/11.0/lib/libc/rpc/clnt_vc.c:432 #3 0x000000000040250b in ypxfr_get_map (map=0x7fffffffe27c "rpc.byname", domain=0x800dcfc40 "xyzzy", host=<value optimized out>, callback=0x402570 <ypxfr_foreach>) at /.../hal/z/SRC/FreeBSD/releng/11.0/libexec/ypxfr/ypxfr_getmap.c:85 #4 0x0000000000402eab in main (argc=<value optimized out>, argv=<value optimized out>) at /.../hal/z/SRC/FreeBSD/releng/11.0/libexec/ypxfr/ypxfr_main.c:517 #5 0x0000000000401c4f in _start () #6 0x0000000800628000 in ?? () #7 0x0000000000000000 in ?? () (gdb) q [0]# [0]# gdb /usr/sbin/yppush yppush.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `yppush'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000000000000 in ?? () (gdb) where #0 0x0000000000000000 in ?? () #1 0x00000008008f44ed in xdr_ypresp_all_seq (xdrs=<value optimized out>, objp=0x7fffffffdcd0) at /.../hal/z/SRC/FreeBSD/releng/11.0/lib/libc/yp/xdryp.c:105 #2 0x0000000800907536 in clnt_vc_call (cl=<value optimized out>, proc=8, xdr_args=0x40182c <xdr_ypreq_nokey@plt>, args_ptr=0x7fffffffdcd8, xdr_results=0x40186c <xdr_ypresp_all_seq@plt>, results_ptr=<value optimized out>, timeout={tv_sec = 10, tv_usec = 0}) at /.../hal/z/SRC/FreeBSD/releng/11.0/lib/libc/rpc/clnt_vc.c:432 #3 0x0000000000401e6b in ypxfr_get_map (map=0x404403 "ypservers", domain=0x7fffffffe226 "xyzzy", host=<value optimized out>, callback=0x402f30 <yppush_foreach>) at /.../hal/z/SRC/FreeBSD/releng/11.0/usr.sbin/yppush/../../libexec/ypxfr/ypxfr_getmap.c:85 #4 0x0000000000402dae in main (argc=<value optimized out>, argv=<value optimized out>) at /.../hal/z/SRC/FreeBSD/releng/11.0/usr.sbin/yppush/yppush_main.c:608 #5 0x0000000000401cff in _start () #6 0x0000000800627000 in ?? () #7 0x0000000000000000 in ?? () (gdb) q [0]#
One more note: My network is fully dual IPv4/IPv6.
Created attachment 175798 [details] proposed patch This looks like a regression from r285926: ypxfr_getmap.c references a couple of libc symbols, and that revision turned them into local symbols. Could you try the attached patch?
That did the trick, thanks. I ran make in libexec/ypxfr and usr.sbin/yppush; any other binaries that would be affected by the change? -- Martin
(In reply to Martin Birgmeier from comment #5) Thanks for testing. ypxfr_getmap.c is only compiled into ypxfr and yppush, so you shouldn't need to recompile anything else.
A commit references this bug: Author: markj Date: Sun Oct 16 19:12:22 UTC 2016 New revision: 307398 URL: https://svnweb.freebsd.org/changeset/base/307398 Log: Reference the libc symbols ypresp_{allfn,data} instead of local symbols. This fixes a regression introduced in r285926. PR: 213506 MFC after: 3 days Changes: head/libexec/ypxfr/ypxfr_getmap.c
A commit references this bug: Author: markj Date: Wed Oct 19 17:18:48 UTC 2016 New revision: 307642 URL: https://svnweb.freebsd.org/changeset/base/307642 Log: MFC r307398: Reference the libc symbols ypresp_{allfn,data} instead of local symbols. PR: 213506 Changes: _U stable/11/ stable/11/libexec/ypxfr/ypxfr_getmap.c
Did this make it into 11.0-RELEASE ? I'm seeing similar issue with ypxfr when manually initiating a transfer from 11.0 slave to 10.3 master: [/tmp] uname -a FreeBSD tron.ops.inoc.net 11.0-RELEASE-p5 FreeBSD 11.0-RELEASE-p5 #0 r309889: Mon Dec 12 18:35:01 UTC 2016 root@tron.ops.inoc.net:/usr/obj/usr/11.0-RELEASE/sys/ESXBSD amd64 [/tmp] /usr/libexec/ypxfr passwd.byname Segmentation fault (core dumped) [/tmp] gdb /usr/libexec/ypxfr ypxfr.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Core was generated by `ypxfr'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/librpcsvc.so.5...Reading symbols from /usr/lib/debug//usr/lib/librpcsvc.so.5.debug...done. done. Loaded symbols for /usr/lib/librpcsvc.so.5 Reading symbols from /lib/libc.so.7...Reading symbols from /usr/lib/debug//lib/libc.so.7.debug...done. done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...Reading symbols from /usr/lib/debug//libexec/ld-elf.so.1.debug...done. done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000000000000 in ?? () (gdb) bt full #0 0x0000000000000000 in ?? () No symbol table info available. #1 0x0000000800afe53d in xdr_ypresp_all_seq (xdrs=<value optimized out>, objp=0x7fffffffde30) at /usr/11.0-RELEASE/lib/libc/yp/xdryp.c:105 out = {more = 1, ypresp_all_u = {val = {stat = YP_TRUE, val = {valdat_len = 50, valdat_val = 0x0}, key = {keydat_len = 4, keydat_val = 0x0}}}} key = 0x801029128 "doon" val = 0x801015040 "doon:*:1000:400:doon:/home/doon:/usr/local/bin/zsh" r = <value optimized out> #2 0x0000000800b11586 in clnt_vc_call (cl=<value optimized out>, proc=8, xdr_args=0x40178c <xdr_ypreq_nokey@plt>, args_ptr=0x7fffffffde38, xdr_results=0x4017cc <xdr_ypresp_all_seq@plt>, results_ptr=<value optimized out>, timeout= {tv_sec = 10, tv_usec = 0}) at /usr/11.0-RELEASE/lib/libc/rpc/clnt_vc.c:432 refreshes = 2 ct = <value optimized out> newmask = <value optimized out> mask = <value optimized out> xdrs = <value optimized out> shipnow = 1 x_id = <value optimized out> reply_msg = {rm_xid = 2797596429, rm_direction = REPLY, ru = {RM_cmb = {cb_rpcvers = 0, cb_prog = 0, cb_vers = 0, cb_proc = 0, cb_cred = {oa_flavor = 0, oa_base = 0x0, oa_length = 0}, cb_verf = {oa_flavor = 0, oa_base = 0x40173c "ÿ%ÞJ ", oa_length = 0}}, RM_rmb = {rp_stat = MSG_ACCEPTED, ru = {RP_ar = {ar_verf = {oa_flavor = 0, oa_base = 0x0, oa_length = 0}, ar_stat = SUCCESS, ru = {AR_versions = {low = 0, high = 0}, AR_results = {where = 0x0, proc = 0x40173c <xdr_void@plt>}}}, RP_dr = { rj_stat = RPC_MISMATCH, ru = {RJ_versions = {low = 0, high = 0}, RJ_why = AUTH_OK}}}}}} reply_stat = 0 #3 0x000000000040250b in ypxfr_get_map (map=0x7fffffffede3 "passwd.byname", domain=0x800dcf980 "inoc.alb1", host=<value optimized out>, callback=0x402570 <ypxfr_foreach>) at /usr/11.0-RELEASE/libexec/ypxfr/ypxfr_getmap.c:85 clnt = (CLIENT *) 0x80105c120 status = <value optimized out> #4 0x0000000000402eab in main (argc=<value optimized out>, argv=<value optimized out>) at /usr/11.0-RELEASE/libexec/ypxfr/ypxfr_main.c:517 ypxfr_temp_map = 0x7fffffffe6f0 "/var/yp//inoc.alb1/passwd.byname.725" tempmap = 0x7fffffffe2e0 "passwd.byname.725" buf = 0x7fffffffded0 "/var/yp//inoc.alb1/passwd.byname" ypxfr_force = <value optimized out> secure = Cannot access memory at address 0x1 (gdb)
I don't think this made it into 11.0 because I still have that patch in my private patchset for releng/11.0. -- Martin
Indeed, the fix unfortunately didn't make it into 11.0, but will be in 11.1.
Shouldn't this be considered for an errata to 11.0-RELEASE? This pretty much breaks transferring NIS maps to any slave servers in a domain? Anyone who updates/pushes changes will find ypxfer core dumping and maps not being updated. This could also be a security issue if NIS masters are being accurately synced.
I'll work on getting an errata published for this.
Is there a status on the errata on this? We had upgraded four machines to RELENG_11 in the past week and each of them fails to properly sync NIS maps from our masters. The end result is that password changes and account adds/removals don't make it to the hosts without manual intervention. The patch does seem to fix this and I suppose just hand patching src works, but this seems that it can trigger a security issue for those not aware of this problem.
(In reply to Robert Blayzor from comment #14) I don't have any updates yet - I've just filled out and submitted an EN request to the release engineering team. I'll update when I know when the fix is going out.