From owner-freebsd-bugs Mon Jul 8 16:12:28 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA16815 for bugs-outgoing; Mon, 8 Jul 1996 16:12:28 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA16802 for ; Mon, 8 Jul 1996 16:12:12 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id TAA17851; Mon, 8 Jul 1996 19:10:46 -0400 From: Bill Paul Message-Id: <199607082310.TAA17851@skynet.ctr.columbia.edu> Subject: Re: 2.1-960627-SNAP: YP problem To: mikebo@tellabs.com Date: Mon, 8 Jul 1996 19:10:45 -0400 (EDT) Cc: bugs@freebsd.org In-Reply-To: <199607081536.KAA20487@sunc210.tellabs.com> from "mikebo@tellabs.com" at Jul 8, 96 10:36:41 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, mikebo@tellabs.com had to walk into mine and say: > Bill 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. > > > I've also tried the string "+:::::0:0:::" as suggested by Mike Murphy, > but still no difference. This should not matter. For the moment, you only want +::::::::: anyway. To make sure I wasn't nuts, I installed the same SNAP release on the test machine in my office. We should now have a common reference point. I've configured the machine as an NIS and NFS client on my network (using the automounter to get maps via NIS too) and it all seems to work. 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.) > > See if you can do 'id ' and have it recognise the > > user in the NIS passwd map. If this works, then it is reading the > > passwd map correctly. > > > > Check this out: > > toybox> id mikebo > id: mikebo: No such user > toybox> ypmatch mikebo passwd > mikebo:iXmhD1ZBZJbLI:1874:10:Mike Borowiec,D122,8211,:/home/sunc210/mikebo:/bin/ksh Okay, check _this_ out: marple# uname -sr FreeBSD 2.1-960627-SNAP marple# ypwhich sirius.ctr.columbia.edu marple# id wpaul uid=1063(wpaul) gid=21(sysman) groups=21(sysman) 0(wheel) 19(src-lscned) 18(src) 125(devnit) marple# ypmatch wpaul passwd.byname wpaul:tI3sbKCXoOHfY:1063:21:Bill Paul:/homes/wpaul:/bin/tcsh marple# ypmatch 1063 passwd.byuid wpaul:tI3sbKCXoOHfY:1063:21:Bill Paul:/homes/wpaul:/bin/tcsh 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.) 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 If I replace all the +@netgroup entries with just +:::::::::, it also works. I'm also bound to a SunOS 4.1.3 NIS server. > As suggested, I built and installed the following test program: > > #include > #include > #include <---- you don't need this, but whatever > > main(argc, argv) > int argc; > char *argv[]; > { > struct passwd *pw; > char *p, *ep, *salt; > > pw = getpwnam(argv[1]); > salt = pw->pw_passwd; > > printf("Username is: [%s]\n", pw->pw_name); > printf("UID is: [%lu]\n", pw->pw_uid); > printf("Password is : [%s]\n", pw->pw_passwd); > p = (char*)getpass((const char*)"Password:"); > ep = (char*)crypt((const char*)p, (const char*)salt); > printf("EPassword is: [%s]\n", ep); > > exit(0); > } > > > 4) Run the program like this: > > > > $ pwtest nisuser > > > > where 'nisuser' is the username of a user that appears in the NIS > > passwd maps. > > > Here's the output: > toybox> ./pwtest mikebo > Username is: [mikebo] > UID is: [1874] > Password is : [iXmhD1ZBZJbLI] > Password: > EPassword is: [iXmhD1ZBZJbLI] > > Looks good to me, but I still can't login: > sunc210> telnet toybox > Trying 138.111.12.69... > Connected to toybox. > Escape character is '^]'. > > FreeBSD (toybox.hq.tellabs.com) (ttyp1) > > login: mikebo > Password: > Login incorrect Okay, things to check: 1) Are you running kerberos? (probably not, but it's worth a shot. :) 2) Did you upgrade to the SNAP by installing it fresh, or did you 'upgrade' by installing over a previous version? 2a) If you 'upgraded,' did you make sure you have only one version of libc.so.whatever in /usr/lib? 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? 4) Are you _SURE_ they you ran pwd_mkdb after you edited /etc/master.passwd? 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.') 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) 6a) Also do an 'ldd test_program_you_built_earlier' and compare the output with 'ldd /usr/bin/login'. 7) Did you check /var/log/messages for suspicious messages resulting from the failed login attempts? 8) If you log in as root, can you do 'su mikebo?' 8a) If so, if you then type 'whoami' does it say 'mikebo?' > 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 (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 > 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. 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. 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. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================