From owner-freebsd-bugs Fri Nov 8 03:50:06 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA27311 for bugs-outgoing; Fri, 8 Nov 1996 03:50:06 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA27295; Fri, 8 Nov 1996 03:50:04 -0800 (PST) Resent-Date: Fri, 8 Nov 1996 03:50:04 -0800 (PST) Resent-Message-Id: <199611081150.DAA27295@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, hino@nwk.cl.nec.co.jp Received: from research.gate.nec.co.jp (research.gate.nec.co.jp [202.32.8.49]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA27210 for ; Fri, 8 Nov 1996 03:48:33 -0800 (PST) Received: from tomato.nwk.cl.nec.co.jp by research.gate.nec.co.jp (8.7.6+2.6Wbeta7/950912) with ESMTP id UAA28087; Fri, 8 Nov 1996 20:48:25 +0900 (JST) Received: by nwk.cl.nec.co.jp (8.7.6+2.6Wbeta7/6.4JAIN-nwk-gw+2.1) id LAA13437; Fri, 8 Nov 1996 11:48:23 GMT Received: (from hino@localhost) by leek.nwk.cl.nec.co.jp (8.7.5/8.7.3) id UAA19539; Fri, 8 Nov 1996 20:41:59 +0900 (JST) Message-Id: <199611081141.UAA19539@leek.nwk.cl.nec.co.jp> Date: Fri, 8 Nov 1996 20:41:59 +0900 (JST) From: hino@nwk.cl.nec.co.jp Reply-To: hino@nwk.cl.nec.co.jp To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: gnu/1981: ypserv handles null key incorrectly Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 1981 >Category: gnu >Synopsis: ypserv handles null key incorrectly >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Nov 8 03:50:02 PST 1996 >Last-Modified: >Originator: Koji Hino >Organization: NEC >Release: FreeBSD 2.1.5-RELEASE i386 >Environment: FreeBSD leek.nwk.cl.nec.co.jp 2.1.5-RELEASE FreeBSD 2.1.5-RELEASE #0: Thu Aug 22 14:58:12 JST 1996 taniguti@leek.nwk.cl.nec.co.jp:/usr/src/sys/compile/BIG_LEEK i386 But... I think that -current's non-GNU ypserv seems to have the same prob. >Description: While ypserv on FreeBSD works as slave NIS server, this ypserv incorrectly handles null key entry in a specific (buggy) NIS-map. (compared with SunOS 4 ypserv). My master NIS server runs on Sun3, SunOS 4.1.1_U1. When I insert a blank line to /etc/protocols, Sun's NIS system makes BAD protocols.bynumber map which contains entry: key="". Other slave NIS servers on Sun, handle this bad map without any problem. But FreeBSD's NIS server can not handle the map like Sun's in following case: * NIS client asks NIS server to get next entry of the bad entry (key=""). Sun returns correct entry, which is a just next of (key=""). FreeBSD returns first entry in the map. This results NIS clients to go loop! I believe that most incorrect player of this problem is Sun's NIS master server environment, but I wish that FreeBSD could treat this buggy map correctly with some proper fixes... >How-To-Repeat: I do not know whether FreeBSD's NIS master server environment (Makefile, tools) will make these bad map or not, so I can not answer... Of caurse, I can repeat the problem in my environment easily :-) >Fix: /usr/src/gnu/usr.sbin/ypserv/server.c line 346 will be fixed.. >Audit-Trail: >Unformatted: