From owner-freebsd-bugs  Wed May  9 19:50: 6 2001
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 8F82837B423
	for <freebsd-bugs@hub.freebsd.org>; Wed,  9 May 2001 19:50:02 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f4A2o2m97169;
	Wed, 9 May 2001 19:50:02 -0700 (PDT)
	(envelope-from gnats)
Date: Wed, 9 May 2001 19:50:02 -0700 (PDT)
Message-Id: <200105100250.f4A2o2m97169@freefall.freebsd.org>
To: freebsd-bugs@FreeBSD.org
Cc: 
From: Dima Dorfman <dima@unixfreak.org>
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd 
Reply-To: Dima Dorfman <dima@unixfreak.org>
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

The following reply was made to PR bin/27230; it has been noted by GNATS.

From: Dima Dorfman <dima@unixfreak.org>
To: "Jacques A. Vidrine" <n@nectar.com>, quinot@inf.enst.fr,
	FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd 
Date: Wed, 09 May 2001 19:40:48 -0700

 "Jacques A. Vidrine" <n@nectar.com> writes:
 > On Wed, May 09, 2001 at 04:38:23PM -0700, Dima Dorfman wrote:
 > > quinot@inf.enst.fr writes:
 > > > 
 > > > >Number:         27230
 > > > >Category:       bin
 > > > >Synopsis:       Users after NIS lines in /etc/passwd
 > > > 	
 > > > >Description:
 > > > 	Consider a /etc/master.passwd with the following structure:
 > > > root:...
 > > > user1:...
 > > > +:...
 > > > user2:...
 > > > 
 > > > 	ie using NIS ('+' line) AND with a local user declared
 > > > 	after the '+' line.
 > > > 
 > > > 	When both ypbind and rpcbind are running, user2 is seen correctly.
 > > > 
 > > > 	When neither of them is running, running 'id user2' hangs for
 > > > 	75 seconds in getpwnam(), then returns 'no such user'.
 > > > 
 > > > 	When only rpcbind is running, it does not hang but returns
 > > > 	'no such user' immediately.
 > > 
 > > This is an artifact of the introduction of nsswitch.  Basically, when
 > > the database-specific lookup routines return NS_UNAVAIL, the search is
 > > short-circuited.  This is wrong because, as you show, there may be
 > > entries later on for which the routine won't return NS_UNAVAIL.
 > 
 > No, NS_UNAVAIL _should_ short-circuit like  this.  I'll look for a bug
 > in __getpwcompat that returns NS_UNAVAIL inappropriately. 
 
 In this case, it gets returned here:
 
         if(__ypdomain == NULL) {
                 if(_yp_check(&__ypdomain) == 0)
                         return NS_UNAVAIL;
         }
 
 line 512, rev. 1.59 of getpwent.c.
 
 > -- 
 > Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org
 > 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message