Date: Sun, 6 Feb 2005 01:05:24 -0800 From: Andrew Konstantinov <andrei@kableu.com> To: Doug White <dwhite@gumbysoft.com> Cc: freebsd-stable@freebsd.org Subject: Re: 5.3 -> 5 : sshd multiple log entries & login_getclass: unknown class 'root' Message-ID: <20050206090524.GA79029@warrior.kableu.com> In-Reply-To: <20050206065226.GA2103@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050206090524.GA79029>