From owner-freebsd-bugs Mon Jul 8 19:55:16 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA28678 for bugs-outgoing; Mon, 8 Jul 1996 19:55:16 -0700 (PDT) Received: from tellab5.lisle.tellabs.com (tellab5.lisle.tellabs.com [138.111.243.28]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA28673 for ; Mon, 8 Jul 1996 19:55:13 -0700 (PDT) From: mikebo@tellabs.com Received: from sunc210.tellabs.com by tellab5.lisle.tellabs.com with smtp (Smail3.1.29.1 #4) id m0udSwf-0004fHC; Mon, 8 Jul 96 21:54 CDT Received: by sunc210.tellabs.com (SMI-8.6/1.9) id VAA21062; Mon, 8 Jul 1996 21:54:01 -0500 Message-Id: <199607090254.VAA21062@sunc210.tellabs.com> Subject: Re: 2.1-960627-SNAP: YP problem To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Mon, 8 Jul 1996 21:54:00 -0500 (CDT) Cc: mikebo (Mike Borowiec), bugs@freebsd.org In-Reply-To: <199607082310.TAA17851@skynet.ctr.columbia.edu> from "Bill Paul" at Jul 8, 96 07:10:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill - You wrote: > > > Of all the gin joints in all the world, mikebo@tellabs.com had to walk > > > into mine and say: > > > > > I believe a bug has been introduced into the 2.1-960627-SNAP YP code. > > > > As it turns out, netgroups have nothing to do with this problem. It is > > > > a problem with any YP password entries from my Sun server... I've added > > > > +::::::::: when editing the password file (with vipw), but NONE of the > > > > users in the NIS password map can login. > > > > Note that I installed the SNAP completely from scratch - I did _not_ > do an upgrade. (This may have something to do with it - read on.) > I did an install from scratch. toybox> uname -sr FreeBSD 2.1-960627-SNAP toybox> ypwhich sunc.lisle.tellabs.com toybox> id mikebo id: mikebo: No such user toybox> id uid=1874 euid=0(root) gid=10(staff) groups=10(staff), 0(wheel), 14(train), 381(netis), 2(kmem), 4(tty), 237(ecfreq), 111(slip), 380(isstaff), 23(tools), 3(sys), 22(tellab5) toybox> ypmatch mikebo passwd.byname mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh toybox> ypmatch 1874 passwd.byuid mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh > Check that you exist correctly in both the passwd.byname and passwd.byuid > maps. Check also that both of these maps has valid data in them. (By valid > I mean with the correct number of fields and such.) > Looks good to me... > For reference, my /etc/master.passwd looks like this (I don't mind > showing you the encrypted passwords -- they'll be changed shortly :) : > > marple# cat /etc/master.passwd > root:KBO1w243/.2XA:0:0::0:0:Charlie &:/root:/bin/csh > toor:*:0:0::0:0:Bourne-again Superuser:/root: > daemon:*:1:31::0:0:Owner of many system processes:/root: > operator:jNfGj.GU4RB6g:2:20::0:0:System &:/usr/guest/operator:/bin/csh > bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/nonexistent > games:*:7:13::0:0:Games pseudo-user:/usr/games: > news:*:8:8::0:0:News Subsystem:/:/nonexistent > man:*:9:9::0:0:Mister Man Pages:/usr/share/man: > uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico > xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/nonexistent > nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/nonexistent > +@marple-users::::::::: > +@super-people::::::::: > +@SUG-people::32767:32767::::::/usr/local/etc/auth > +@Snet-people::32767:32767::::::/usr/local/etc/auth > +@acorn-people::32767:32767::::::/usr/local/etc/auth > +@ctrnet-people::32767:32767::::::/usr/local/etc/auth > +@image-people::32767:32767::::::/usr/local/etc/auth > +@tnl-people::32767:32767::::::/usr/local/etc/auth > +@sgi-people::32767:32767::::::/usr/local/etc/auth > +@deleted1-people::32767:32767::::::/usr/local/etc/disabled > +@deleted2-people::32767:32767::::::/usr/local/etc/disabled > toybox> cat /etc/master.passwd root:8q0iQ8SRCw2/s:0:0::0:0:Charlie &:/root:/bin/csh kroot:8q0iQ8SRCw2/s:0:0::0:0:Charlie &:/root:/bin/ksh toor:*:0:0::0:0:Bourne-again Superuser:/root: daemon:*:1:31::0:0:Owner of many system processes:/root: operator:*:2:20::0:0:System &:/usr/guest/operator:/bin/csh bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/nonexistent games:*:7:13::0:0:Games pseudo-user:/usr/games: news:*:8:8::0:0:News Subsystem:/:/nonexistent man:*:9:9::0:0:Mister Man Pages:/usr/share/man: uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/nonexistent nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/nonexistent +::::::::: > Okay, things to check: > > 1) Are you running kerberos? (probably not, but it's worth a shot. :) NO. (Yuck ;v) > 2) Did you upgrade to the SNAP by installing it fresh, or did you 'upgrade' > by installing over a previous version? Fresh. New filesystems and all... > 2a) If you 'upgraded,' did you make sure you have only one version of > libc.so.whatever in /usr/lib? N/A. > 3) Are you _SURE_ that you don't have an entry in your /etc/master.passwd > file that says +::0:0::::::? Maybe one you missed? No... see above. > 4) Are you _SURE_ they you ran pwd_mkdb after you edited > /etc/master.passwd? I never edited /etc/master.passwd. I only used vipw which is supposed to do this for me. For grins, I tried it. No difference... > 5) Did you re-run ldconfig after you installed the DES package? (Rebooting > accomplishes the same thing -- if you've rebooted the machine since the > DES package went in, the answer is 'yes.') I've reboot several times. > 6) If you do 'ldd /usr/bin/login' does it show it to be linking against > the correct version of libc.so.whatever? > > For reference, this is what it says for me: > > marple# ldd /usr/bin/login > /usr/bin/login: > -lutil.2 => /usr/lib/libutil.so.2.1 (0x801d000) > -lskey.2 => /usr/lib/libskey.so.2.0 (0x802c000) > -lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8032000) > -lc.2 => /usr/lib/libc.so.2.2 (0x8047000) > toybox> ldd /usr/bin/login /usr/bin/login: -lutil.2 => /usr/lib/libutil.so.2.1 (0x801e000) -lskey.2 => /usr/lib/libskey.so.2.0 (0x802d000) -lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8033000) -lc.2 => /usr/lib/libc.so.2.2 (0x8048000) This doesn't look right... but the program I built earlier looks OK. See below... why wouldn't the numbers match? > 6a) Also do an 'ldd test_program_you_built_earlier' and compare the > output with 'ldd /usr/bin/login'. toybox> ldd /home/sunc210/mikebo/tmp/pwtest /home/sunc210/mikebo/tmp/pwtest: -lutil.2 => /usr/lib/libutil.so.2.1 (0x801d000) -lskey.2 => /usr/lib/libskey.so.2.0 (0x802c000) -lcrypt.2 => /usr/lib/libcrypt.so.2.0 (0x8032000) -ldes.2 => /usr/lib/libdes.so.2.1 (0x8047000) -lc.2 => /usr/lib/libc.so.2.2 (0x8053000) > 7) Did you check /var/log/messages for suspicious messages resulting > from the failed login attempts? Yes, there were no suspicious messages. > 8) If you log in as root, can you do 'su mikebo?' su: no such login: mikebo > 8a) If so, if you then type 'whoami' does it say 'mikebo?' N/A. > > > Looks like NIS is working fine, and some programs/libraries are simply > > ignoring the fact that there are valid YP tokens in the passwd files. > > Well, all the references are either within libc, or inside a small number > of statically linked programs (e.g. those in /bin). I'm beginning to > suspect a libc mismatch of some kind. These are the C libraries I have > on my system: > > marple# ls -l /usr/lib/libc.* > -r--r--r-- 1 bin bin 497710 Jun 28 04:44 /usr/lib/libc.a > -r--r--r-- 1 bin bin 435727 Jun 28 04:44 /usr/lib/libc.so.2.2 > toybox> ls -l /usr/lib/libc.* -r--r--r-- 1 bin bin 497710 Jun 28 03:44 /usr/lib/libc.a -r--r--r-- 1 bin bin 403106 Jul 3 1994 /usr/lib/libc.so.1.1 -r--r--r-- 1 bin bin 466907 Jan 25 1995 /usr/lib/libc.so.2.0 -r--r--r-- 1 bin bin 435248 Apr 27 16:57 /usr/lib/libc.so.2.2 Now how did this happen? I installed via FTP from the default server listed in the install dialogue. toybox> cksum /usr/lib/libc.so.2.2 3292964480 435248 /usr/lib/libc.so.2.2 > (Note that I don't have the profiled libraries installed. This shouldn't > make any difference.) > > My libcrypt setup looks like this (sorry for the long lines): > > marple# ls -l /usr/lib/*crypt* > lrwxr-xr-x 1 bin bin 13 Jul 5 14:07 /usr/lib/libcrypt.a -> libdescrypt.a > lrwxr-xr-x 1 bin bin 18 Jul 5 14:07 /usr/lib/libcrypt.so.2.0 -> libdescrypt.so.2.0 > lrwxr-xr-x 1 bin bin 15 Jul 5 14:07 /usr/lib/libcrypt_p.a -> libdescrypt_p.a > -r--r--r-- 1 bin bin 10690 Jun 28 04:47 /usr/lib/libdescrypt.a > -r--r--r-- 1 bin bin 18145 Jun 28 04:47 /usr/lib/libdescrypt.so.2.0 > -r--r--r-- 1 bin bin 12362 Jun 28 04:47 /usr/lib/libdescrypt_p.a > -r--r--r-- 1 bin bin 4576 Jun 28 04:47 /usr/lib/libscrypt.a > -r--r--r-- 1 bin bin 12755 Jun 28 04:47 /usr/lib/libscrypt.so.2.0 > toybox> ls -l /usr/lib/*crypt* lrwxr-xr-x 1 bin bin 13 Jul 3 12:51 /usr/lib/libcrypt.a -> libdescrypt.a lrwxr-xr-x 1 bin bin 18 Jul 3 12:51 /usr/lib/libcrypt.so.2.0 -> libdescrypt.so.2.0 lrwxr-xr-x 1 bin bin 15 Jul 3 12:51 /usr/lib/libcrypt_p.a -> libdescrypt_p.a -r--r--r-- 1 bin bin 10690 Jun 28 03:47 /usr/lib/libdescrypt.a -r--r--r-- 1 bin bin 18145 Jun 28 03:47 /usr/lib/libdescrypt.so.2.0 -r--r--r-- 1 bin bin 12362 Jun 28 03:47 /usr/lib/libdescrypt_p.a -r--r--r-- 1 bin bin 4576 Jun 28 03:47 /usr/lib/libscrypt.a -r--r--r-- 1 bin bin 12755 Jun 28 03:47 /usr/lib/libscrypt.so.2.0 -r--r--r-- 1 bin bin 5080 Jun 28 03:47 /usr/lib/libscrypt_p.a > > The DES package was installed at the same time as the install, and all > > appeared to complete flawlessly. The login program: > > toybox> ls -l /usr/bin/login > > -r-sr-xr-x 1 root bin 20480 Jun 28 03:59 /usr/bin/login > > toybox> cksum /usr/bin/login > > 957853657 20480 /usr/bin/login > > > > I appreciate all the help. What next? > > This depends on whether you did a complete reinstall or an upgrade. I did a complete install, including newfs of both / and /usr. > The reason I'm curious is this: I did change the getpwent(3) code in > libc rather substantially between the June 27th SNAP and the previous > one. Actually, what I did was sync the 2.1-STABLE version with the > 2.2-current version, which had survived for several weeks in the > -current tree without any trouble (no angry mobs came calling for my > head), so I moved it over. The newer version is a bit less messy than > the previous one and fixes some bugs. Also, /usr/include/pwd.h and > /usr/sbin/pwd_mkdb changed a little since they and getpwent(3) > are intimately related. > toybox> ls -l /usr/include/pwd.h /usr/sbin/pwd_mkdb -r--r--r-- 1 bin bin 4118 Jun 28 03:44 /usr/include/pwd.h -r-xr-xr-x 1 bin bin 12288 Jun 28 04:04 /usr/sbin/pwd_mkdb > The result is that if you somehow managed to keep an older version of > libc.so around (like from the previous SNAP) you might have conflicts since > the older getpwent(3) NIS code is not strictly forward compatible (the > new version is backward compatible though). Basically, if you use the > new pwd_mkdb to create a hash user database with NIS entries, the old > getpwent(3) will not be able to grok it properly. This sounds a lot like > what's happening here. > Indeed... again, I installed from scratch via FTP using the default server in the install dialogue. I can't remember the hostname, but I assume it's ftp.freebsd.org. Note that I do appear to have an older libc.so.2.2. Perhaps the install program screwed me up - but how? Thanks again for spending so much time. Regards, - Mike -- -------------------------------------------------------------------------- Michael Borowiec - mikebo@tellabs.com - Tellabs Operations Inc. Senior Member of Technical Staff 4951 Indiana Avenue, MS 63 708-512-8211 FAX: 708-512-7099 Lisle, IL 60532 USA --------------------------------------------------------------------------