From owner-freebsd-stable@FreeBSD.ORG Sun Feb 6 09:05:27 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49D7016A4CE for ; Sun, 6 Feb 2005 09:05:27 +0000 (GMT) Received: from pop-a065c05.pas.sa.earthlink.net (pop-a065c05.pas.sa.earthlink.net [207.217.121.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0A8143D4C for ; Sun, 6 Feb 2005 09:05:26 +0000 (GMT) (envelope-from andrei@kableu.com) Received: from h-69-3-28-133.snvacaid.dynamic.covad.net ([69.3.28.133] helo=mail.kableu.com) by pop-a065c05.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CxiM9-0000FH-00; Sun, 06 Feb 2005 01:05:25 -0800 Received: from warrior.kableu.com (warrior.kableu.com [192.168.0.1]) by mail.kableu.com (Postfix) with ESMTP id ABEBCC0E1; Sun, 6 Feb 2005 01:05:24 -0800 (PST) Received: by warrior.kableu.com (Postfix, from userid 1001) id 6CC741144C; Sun, 6 Feb 2005 01:05:24 -0800 (PST) Date: Sun, 6 Feb 2005 01:05:24 -0800 From: Andrew Konstantinov To: Doug White Message-ID: <20050206090524.GA79029@warrior.kableu.com> References: <20050130084359.GA36069@warrior.kableu.com> <20050201012056.GA47334@warrior.kableu.com> <20050202070820.GA26302@warrior.kableu.com> <20050203210643.T47315@carver.gumbysoft.com> <20050206061245.GA1774@warrior.kableu.com> <20050206065226.GA2103@warrior.kableu.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20050206065226.GA2103@warrior.kableu.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-stable@freebsd.org Subject: Re: 5.3 -> 5 : sshd multiple log entries & login_getclass: unknown class 'root' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 09:05:27 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 05, 2005 at 10:52:26PM -0800, Andrew Konstantinov wrote: > On Sat, Feb 05, 2005 at 10:12:45PM -0800, Andrew Konstantinov wrote: > > On Thu, Feb 03, 2005 at 09:11:07PM -0800, Doug White wrote: > > > On Tue, 1 Feb 2005, Andrew Konstantinov wrote: > > >=20 > > > > > > I can't reproduce this on my systems, many of which started at = 5.3 and now > > > > > > build 5-stable. Are you using the system ssh or one you built = from ports? > > > > > > > > > > > > What is the output of 'ls -l /etc/login.conf*'? > > > > > > > > I knew I wasn't hallucinating. When I rebuild and reinstall src/lib= /libc > > > > from RELENG_5_3 sources on RELENG_5 system, all of the above proble= ms > > > > disappear altogether. The bugs are in the dynamically linked library > > > > that sshd relies on. Once the new library is in place and > > > > "/etc/rc.d/sshd restart" is performed, the bugs disappear. I don't = have > > > > time to dig into that right now, but I'll be back with patches. > > >=20 > > > The simple fact stands that noone else can reproduce this, which lead= s me > > > to believe you took a non-standard approach to upgrading, and therefo= re > > > are getting what you asked for. :-) > > >=20 > > > If you can provide exact reproduction steps, starting from bare metal, > > > I'll follow them. > >=20 > > The other important thing that I've noticed is that when I set > > UsePrivilegeSeparation in sshd_config to "no", all those bugs disappear. >=20 > Also, when I traced sshd in debug mode using gdb, I've found that > /usr/src/lib/libc/gen/getcap.c lines 246 - 274 work properly and return t= he > valid "root" entry from the login database and that code is enclosed in t= he > else statement that is a part of "if (fd >=3D 0)" construction. So, I app= arently, > something gets to getent around cgetent with already existing file > descriptor which causes a different portion of code to be executed > (instead of 246 - 274) which in its turn causes a problem. Perhaps the > descriptor is poing to a wrong file? First of all, I apologize for the incorrect diagnosis. The real bug is not = in the upgrade from RELENG_5_3 to RELENG_5. Secure shell's odd behavior is cau= sed by "NO_NIS=3Dtrue" in the /etc/make.conf. The reason why the bug disappeare= d when I reversed src/lib/libc from RELENG_5 back to RELENG_5_3 is because of: warrior# cvs rdiff -u -rRELENG_5_3 -rRELENG_5 src/lib/libc/Makefile Index: src/lib/libc/Makefile diff -u src/lib/libc/Makefile:1.52 src/lib/libc/Makefile:1.52.2.1 --- src/lib/libc/Makefile:1.52 Fri May 14 12:04:29 2004 +++ src/lib/libc/Makefile Sun Nov 28 14:10:16 2004 @@ -1,5 +1,5 @@ # @(#)Makefile 8.2 (Berkeley) 2/3/94 -# $FreeBSD: src/lib/libc/Makefile,v 1.52 2004/05/14 12:04:29 cognet Exp $ +# $FreeBSD: src/lib/libc/Makefile,v 1.52.2.1 2004/11/28 14:10:16 bz Exp $ # # All library objects contain FreeBSD revision strings by default; they ma= y be # excluded as a space-saving measure. To produce a library that does @@ -60,7 +60,7 @@ .if ${MACHINE_ARCH} =3D=3D "arm" .include "${.CURDIR}/softfloat/Makefile.inc" .endif -.if !defined(NO_YP_LIBC) +.if !defined(NO_NIS) CFLAGS+=3D -DYP .include "${.CURDIR}/yp/Makefile.inc" .endif When I reversed my system back to RELENG_5_3, that effectively disabled the= "NO_NIS=3Dtrue" flag in /etc/make.conf. So, the good news is that I get to= have clean logs after removal of "NO_NIS=3Dtrue" from /etc/make.conf. *Possible* exact reproduction steps: - install RELENG_5 - rebuild RELENG_5 with "NO_NIS=3Dtrue" in /etc/make.conf - restart sshd service The reason why they are "possible" is because I'm not sure if that is the o= nly condition that has to be present in the system in order for the bug to appe= ar. Can anyone confirm this? Andrew --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCBd3Ug+6MtxSjexcRAnMUAKCVuAeaQhhGncVXZ/Eb7HiJyOV/JQCgwVX7 czXGuNQCQNDjoGYEwrOw5pk= =ycwE -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--