5.3 -> 5 : sshd multiple log entries & login_getclass: unknown class 'root'

[Andrew Konstantinov]

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:
> > > 
> > > > > > 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 problems
> > > > 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.
> > > 
> > > The simple fact stands that noone else can reproduce this, which leads me
> > > to believe you took a non-standard approach to upgrading, and therefore
> > > are getting what you asked for. :-)
> > > 
> > > If you can provide exact reproduction steps, starting from bare metal,
> > > I'll follow them.
> > 
> > The other important thing that I've noticed is that when I set
> > UsePrivilegeSeparation in sshd_config to "no", all those bugs disappear.
> 
> 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 the
> valid "root" entry from the login database and that code is enclosed in the
> else statement that is a part of "if (fd >= 0)" construction. So, I apparently,
> 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 caused
by "NO_NIS=true" in the /etc/make.conf. The reason why the bug disappeared 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 may be
 # excluded as a space-saving measure.  To produce a library that does
@@ -60,7 +60,7 @@
 .if ${MACHINE_ARCH} == "arm"
 .include "${.CURDIR}/softfloat/Makefile.inc"
 .endif
-.if !defined(NO_YP_LIBC)
+.if !defined(NO_NIS)
 CFLAGS+= -DYP
 .include "${.CURDIR}/yp/Makefile.inc"
 .endif

When I reversed my system back to RELENG_5_3, that effectively disabled the "NO_NIS=true" flag in /etc/make.conf. So, the good news is that I get to have clean logs after removal of "NO_NIS=true" from /etc/make.conf.

*Possible* exact reproduction steps:
- install RELENG_5
- rebuild RELENG_5 with "NO_NIS=true" in /etc/make.conf
- restart sshd service

The reason why they are "possible" is because I'm not sure if that is the only
condition that has to be present in the system in order for the bug to appear.

Can anyone confirm this?

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050206/759bb1f0/attachment.bin