Date: Wed, 9 May 2001 19:20:02 -0700 (PDT) From: "Jacques A. Vidrine" <n@nectar.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/27230: Users after NIS lines in /etc/passwd Message-ID: <200105100220.f4A2K2794881@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR bin/27230; it has been noted by GNATS.
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105100220.f4A2K2794881>