From quinot@inf.enst.fr  Wed May  9 09:02:33 2001
Return-Path: <quinot@inf.enst.fr>
Received: from infres.enst.fr (infres.enst.fr [137.194.160.3])
	by hub.freebsd.org (Postfix) with ESMTP id 65B7637B423
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  9 May 2001 09:02:33 -0700 (PDT)
	(envelope-from quinot@inf.enst.fr)
Received: from shalmaneser.enst.fr (shalmaneser.enst.fr [137.194.160.128])
	by infres.enst.fr (Postfix) with ESMTP id 672D818BA
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  9 May 2001 18:02:32 +0200 (MET DST)
Received: by shalmaneser.enst.fr (Postfix, from userid 11117)
	id 6E0B91131B; Wed,  9 May 2001 18:02:31 +0200 (CEST)
Message-Id: <20010509160231.6E0B91131B@shalmaneser.enst.fr>
Date: Wed,  9 May 2001 18:02:31 +0200 (CEST)
From: quinot@inf.enst.fr
Reply-To: quinot@inf.enst.fr
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Users after NIS lines in /etc/passwd
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         27230
>Category:       bin
>Synopsis:       Users after NIS lines in /etc/passwd
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    nectar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 09 09:10:01 PDT 2001
>Closed-Date:    Tue Feb 04 19:24:11 PST 2003
>Last-Modified:  Wed Feb  5 04:50:08 PST 2003
>Originator:     Thomas Quinot
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD shalmaneser.enst.fr 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Wed May 9 16:43:38 CEST 2001 root@shalmaneser.enst.fr:/usr/obj/usr/src/sys/SHALMANESER i386


	
>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.

	There is a similar problem with /etc/groups, which had
	the unfortunate on my system that the
	  chown root:wheel /dev/tty[pqrsPQRS]*
	in /etc/rc took ages, because '+' was before 'wheel' in
	my /etc/groups.

>How-To-Repeat:
	* killall rpcbind ypbind
        * id user1 (where user1 is a username before the '+'): OK
        * id user2 (------------------------- after  -------):
           hangs for 75 seconds then returns 'unknown user')
        * launch rpcbind
        * id user2 now returns 'unknwon user' immediately
        * launch ypbind
        * id user2 works OK

>Fix:
        Fix: unknown.

        Work-around: Move all the '+' lines in /etc/master.passwd and /etc/group
        to the end of the file. Document the problem. Possibly modify
        vipw to do the rearrangement automatically when generating /etc/passwd
        from master.passwd.
>Release-Note:
>Audit-Trail:

From: Dima Dorfman <dima@unixfreak.org>
To: quinot@inf.enst.fr
Cc: FreeBSD-gnats-submit@freebsd.org, nectar@freebsd.org
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd 
Date: Wed, 09 May 2001 16:38:23 -0700

 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.
 
 The attached patch seems to fix this for me.  Please try it and see if
 it works for you, too.  If you're not confident with being able to
 rebuild libc and the appropriate programs correctly, you'll probably
 want to do a full make world.
 
 > 	There is a similar problem with /etc/groups, which had
 > 	the unfortunate on my system that the
 > 	  chown root:wheel /dev/tty[pqrsPQRS]*
 > 	in /etc/rc took ages, because '+' was before 'wheel' in
 > 	my /etc/groups.
 
 This problem doesn't seem to affect groups.  I can't reproduce it, and
 a quick look at the code supports this observation.  Perhaps there
 were other causes for the delay you describe above.
 
 					Dima Dorfman
 					dima@unixfreak.org
 
 Index: getpwent.c
 ===================================================================
 RCS file: /st/src/FreeBSD/src/lib/libc/gen/getpwent.c,v
 retrieving revision 1.59
 diff -u -r1.59 getpwent.c
 --- getpwent.c	2001/01/24 12:59:22	1.59
 +++ getpwent.c	2001/05/09 23:27:55
 @@ -910,7 +910,7 @@
  				r = __getpwcompat(_PW_KEYBYNAME, 0, user);
  
  				if (r == NS_UNAVAIL)
 -					return r;
 +					break;
  				if (r == NS_NOTFOUND) {
  					/*
  					 * just because this user is bad
 @@ -924,7 +924,7 @@
  				r = __getpwcompat(_PW_KEYBYNAME, 0, user);
  
  				if (r == NS_UNAVAIL)
 -					return r;
 +					break;
  				if (r == NS_NOTFOUND)
  					continue;
  				break;

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

 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. 
 -- 
 Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org

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
 > 

From: Thomas Quinot <quinot@inf.enst.fr>
To: "Jacques A. Vidrine" <n@nectar.com>,
	Dima Dorfman <dima@unixfreak.org>, FreeBSD-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd
Date: Thu, 10 May 2001 09:46:04 +0200

 Le 2001-05-10, Jacques A. Vidrine crivait :
 
 > No, NS_UNAVAIL _should_ short-circuit like  this.  I'll look for a bug
 > in __getpwcompat that returns NS_UNAVAIL inappropriately. 
 
 BTW: In case this information is needed, the contents of my /etc/nsswitch.conf
 is:
 
 hosts: files [NOTFOUND=continue] dns
 
 -- 
 Thomas Quinot ** Dpartement Informatique & Rseaux ** quinot@inf.enst.fr
               ENST   //   46 rue Barrault   //   75634 PARIS CEDEX 13 

From: Thomas Quinot <quinot@inf.enst.fr>
To: Dima Dorfman <dima@unixfreak.org>
Cc: "Jacques A. Vidrine" <n@nectar.com>, quinot@inf.enst.fr,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd
Date: Thu, 10 May 2001 12:58:23 +0200

 Le 2001-05-10, Dima Dorfman crivait :
 
 > > 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.
 
 As I understand it, your patch and/or changing the returned value would
 resolve the faulty 'no such user' error, but not the 75-second hang
 that is experienced when rpcbind is not running.
 
 -- 
 Thomas Quinot ** Dpartement Informatique & Rseaux ** quinot@inf.enst.fr
               ENST   //   46 rue Barrault   //   75634 PARIS CEDEX 13 

From: Dima Dorfman <dima@unixfreak.org>
To: Thomas Quinot <quinot@inf.enst.fr>
Cc: "Jacques A. Vidrine" <n@nectar.com>,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd 
Date: Thu, 10 May 2001 20:27:32 -0700

 Thomas Quinot <quinot@inf.enst.fr> writes:
 > Le 2001-05-10, Dima Dorfman crivait :
 > 
 > > > 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.
 > 
 > As I understand it, your patch and/or changing the returned value would
 > resolve the faulty 'no such user' error, but not the 75-second hang
 > that is experienced when rpcbind is not running.
 
 I don't think that's a bug.  It's the nature of NIS; it should wait in
 hopes of the server responding.  Perhaps the bug is that it doesn't
 wait when rpcbind is running but ypbind isn't.
 
 > 
 > -- 
 > Thomas Quinot ** Dpartement Informatique & Rseaux ** quinot@inf.enst.fr
 >               ENST   //   46 rue Barrault   //   75634 PARIS CEDEX 13 
 > 

From: Thomas Quinot <quinot@inf.enst.fr>
To: Dima Dorfman <dima@unixfreak.org>
Cc: Thomas Quinot <quinot@inf.enst.fr>,
	"Jacques A. Vidrine" <n@nectar.com>, FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd
Date: Fri, 11 May 2001 16:50:51 +0200

 Le 2001-05-11, Dima Dorfman crivait :
 
 > > As I understand it, your patch and/or changing the returned value would
 > > resolve the faulty 'no such user' error, but not the 75-second hang
 > > that is experienced when rpcbind is not running.
 
 > I don't think that's a bug.  It's the nature of NIS; it should wait in
 > hopes of the server responding.  Perhaps the bug is that it doesn't
 > wait when rpcbind is running but ypbind isn't.
 
 In that case perhaps we could change the code to use TCP when trying to
 connect to the local portmapper, so we can get a 'connection refused'
 immediately rather than timing out when there is no portmapper running.
 
 If this is not possible, then the fact that all '+' lines in /etc/passwd
 and /etc/groups should be at the end of the file should IMO be documented.
 
 Thomas.
 
 -- 
 Thomas Quinot ** Dpartement Informatique & Rseaux ** quinot@inf.enst.fr
               ENST   //   46 rue Barrault   //   75634 PARIS CEDEX 13 
Responsible-Changed-From-To: freebsd-bugs->nectar 
Responsible-Changed-By: nectar 
Responsible-Changed-When: Fri May 11 12:46:33 PDT 2001 
Responsible-Changed-Why:  
Make this PR bug me so I can look at it again in a 
couple of weeks.  I'm not convinced there is a problem 
in the lookup code, but I'm hitting the road and won't 
be able to set up a decent test environment until then. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27230 
State-Changed-From-To: open->closed 
State-Changed-By: nectar 
State-Changed-When: Tue Feb 4 19:19:50 PST 2003 
State-Changed-Why:  
If memory serves...  the behavior seen is the expected and 
correct behavior. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=27230 

From: Thomas Quinot <quinot@inf.enst.fr>
To: Jacques Vidrine <nectar@FreeBSD.org>
Cc: bug-followup@freebsd.org
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd
Date: Wed, 5 Feb 2003 12:17:14 +0100

 Le 2003-02-05, Jacques Vidrine crivait :
 
 > State-Changed-From-To: open->closed
 > State-Changed-By: nectar
 > State-Changed-When: Tue Feb 4 19:19:50 PST 2003
 > State-Changed-Why: 
 > If memory serves...  the behavior seen is the expected and
 > correct behavior.
 
 What about using TCP instead of UDP for communication between ypbind
 and rpcbind? This would suppress the 75 second timeout when rpcbind
 is not running.
 
 -- 
 Thomas Quinot ** Dpartement Informatique & Rseaux ** quinot@inf.enst.fr
               ENST   //   46 rue Barrault   //   75634 PARIS CEDEX 13 

From: "Jacques A. Vidrine" <nectar@FreeBSD.org>
To: Thomas Quinot <quinot@inf.enst.fr>
Cc: bug-followup@freebsd.org
Subject: Re: bin/27230: Users after NIS lines in /etc/passwd
Date: Wed, 5 Feb 2003 06:40:48 -0600

 On Wed, Feb 05, 2003 at 12:17:14PM +0100, Thomas Quinot wrote:
 > Le 2003-02-05, Jacques Vidrine $BqD(Brivait :
 > 
 > > State-Changed-From-To: open->closed
 > > State-Changed-By: nectar
 > > State-Changed-When: Tue Feb 4 19:19:50 PST 2003
 > > State-Changed-Why: 
 > > If memory serves...  the behavior seen is the expected and
 > > correct behavior.
 > 
 > What about using TCP instead of UDP for communication between ypbind
 > and rpcbind? This would suppress the 75 second timeout when rpcbind
 > is not running.
 
 That would be optimizing for the unusual case.
 
 Cheers,
 -- 
 Jacques A. Vidrine <nectar@celabo.org>          http://www.celabo.org/
 NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
 jvidrine@verio.net     .  nectar@FreeBSD.org  .          nectar@kth.se
>Unformatted:
