From nobody  Tue Jun 17 09:22:22 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA21362;
          Tue, 17 Jun 1997 09:22:22 -0700 (PDT)
Message-Id: <199706171622.JAA21362@hub.freebsd.org>
Date: Tue, 17 Jun 1997 09:22:22 -0700 (PDT)
From: jose@we.lc.ehu.es
To: freebsd-gnats-submit@freebsd.org
Subject: NIS-only netgroup lookups don't work
X-Send-Pr-Version: www-1.0

>Number:         3891
>Category:       bin
>Synopsis:       NIS-only netgroup lookups don't work
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 17 09:30:01 PDT 1997
>Closed-Date:    Mon Oct 13 12:44:41 PDT 1997
>Last-Modified:  Mon Oct 13 12:54:47 PDT 1997
>Originator:     Jose M. Alcaide
>Release:        FreeBSD 2.2.1-RELEASE i386
>Organization:
Univ. Pais Vasco - Dept. Electronica
>Environment:
FreeBSD tiburon.we.lc.ehu.es 2.2.1-RELEASE FreeBSD 2.2.1-RELEASE #0: Wed May 28 17:05:27 CEST 1997     root@tiburon.we.lc.ehu.es:/usr/src/sys/compile/TIBURON  i386
>Description:
innetgr() fails when a NIS-only lookup is performed, i.e., when
/etc/netgroup doesn't exist, is empty, or contains only "+".
However, when /etc/netgroup contains a direct netgroup specification
followed by a "+", then innetgr() works.
>How-To-Repeat:
An NIS server must exist in the LAN exporting one or more netgroups.
In my case, there is only one netgroup:
	trusted (polaris,-,) (sirius,-,) (vega,-,) .... and so on

The system running FreeBSD must have NIS enabled, ypbind running, etc.
Check that NIS maps are readable using "ypcat". Check that /etc/netgroup
doesn't exist.

Then a simple program like this shows the problem (substitute for your
netgroup, host and NIS domain).

---------------------------------------
#include <stdio.h>

main()
{
  printf("%d\n", innetgr("trusted", "polaris", NULL, "we.lc.ehu.es"));
}
--------------------------------------

This program prints "0": innetgr() fails.

Now, create a /etc/netgroup file containing something like this:

	null (-,-,)
	+

Then, if you run the same program, it will print "1", showing that
innetgr() finds the host in the netgroup.
>Fix:
None. I examined /usr/src/lib/libc/gen/getnetgrent.c, but it's
difficult to find the problem without debugging.

There is an obvious workaround: create /etc/netgroup containing
a dummy netgroup and a "+" entry. However, netgroup(5) says that
this is the least efficient configuration.
>Release-Note:
>Audit-Trail:

From: jose@we.lc.ehu.es (Jose M. Alcaide)
To: FreeBSD-gnats@freebsd.org, freebsd-bugs@freebsd.org
Cc:  Subject: Re: bin/3891: NIS-only netgroup lookups don't work
Date: Wed, 18 Jun 1997 17:53:09 +0200

 I have been working a bit more on this problem. After a closer look to
 the function innetgr() in getnetgrent.c, I'm turning to think that
 there is a problem with a call to yp_match() (see getnetgrent.c, lines
 349 to 352).
 
 I have been trying the command "ypmatch" on several hosts at our network
 (some of them are SPARCs running SunOS 4.1.3, others are SGIs running IRIX 6.x,
 and also FreeBSD 2.2.1 boxes). For example,
 
   jose@tiburon[~]: ypmatch -k trusted netgroup
   trusted (polaris,-,) (sirius,-,) (vega,-,)     ......
 
 Well, this works. However,
 
   jose@tiburon[~]: ypmatch -k polaris netgroup.byhost
   Can't match key polaris in map netgroup.byhost. Reason: no such map in server's domain
 
 I get this message on all NIS (YP) clients, whatever the OS they run. Now,
 I think that the NIS server does not export any maps "netgroup.byXXX".
 I must say that our NIS server is, actually, an NIS+ server running in YP
 compatibility mode; perhaps this is the source of the problem. Unfortunately,
 I have no access to a "true" NIS server.
 
 In any case, the innetgr() implemented by other UNIXes (SunOS 4.x, IRIX
 6.x, Linux, etc.) do work. Perhaps, the FreeBSD's netgroup scheme,
 which tries to optimize NIS-only lookups, _needs_ the "netgroup.byhost"
 map; on the contrary, other UNIXes may perform a sequential lookup in the
 "netgroup" map, and this method does not need "netgroup.byhost".
 
 I have seen in the innetgr() code a "CHARITABLE" flag which, if turned on,
 forces a "standard mode" lookup if the "NIS-exclusive mode" fails. I think
 that a recompilation of getnetgrent.c with -DCHARITABLE will solve (more
 precisely, will _dissolve_) this innetgr() problem.
 
 Greetings,
 --JM
 ------------------------------------------------------------------------
 Jose M. Alcaide                         | E-mail: <jose@we.lc.ehu.es>
 Universidad del Pais Vasco              | WWW:
 Dpto. de Electricidad y Electronica     |  http://www.we.lc.ehu.es/~jose
 Facultad de Ciencias - Campus de Lejona | Phone:  +34-4-4647700 x2624
 48940 Lejona (Vizcaya) - SPAIN          | Fax:    +34-4-4858139
 ------------------------------------------------------------------------
 
State-Changed-From-To: open->closed 
State-Changed-By: wpaul 
State-Changed-When: Mon Oct 13 12:44:41 PDT 1997 
State-Changed-Why:  

Fixed in revision 1.22 in FreeBSD-current and revision 1.17.2.3 in 
RELENG_2_2 of src/lib/libc/gen/getnetgrent.c. The bug was indeed due 
to an NIS+ compatibility problem: the Sun rpc.nisd in YP compat mode 
does not support the 'reverse' netgroup maps (netgroup.byhost and 
netgroup.byuser). The code has been modified such that if a yp_match() 
on the 'reverse' maps yields a YPERR_MAP (no such map in server's domain) 
error, it will fail over to the 'slow' lookup method. The original 
#ifdef CHARITABLE/#endif code was not quite correct as it would yield 
a failover on any error; this is not the desired behavior since it 
could result in a failed lookup being performed twice. (I must have 
realized the code was wrong on some subconsious level which is why it 
was #ifdef'ed out.) 

This fix will be in 2.2.5-RELEASE. 

-Bill 
>Unformatted:
