From owner-freebsd-bugs Wed Jul 3 18:32:38 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA14543 for bugs-outgoing; Wed, 3 Jul 1996 18:32:38 -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 SAA14530 for ; Wed, 3 Jul 1996 18:32:28 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id VAA03325; Wed, 3 Jul 1996 21:25:24 -0400 From: Bill Paul Message-Id: <199607040125.VAA03325@skynet.ctr.columbia.edu> Subject: Re: 2.1-960627-SNAP: YP problem To: mikebo@tellabs.com Date: Wed, 3 Jul 1996 21:25:22 -0400 (EDT) Cc: bugs@freebsd.org In-Reply-To: <199607032025.PAA13743@sunc210.tellabs.com> from "mikebo@tellabs.com" at Jul 3, 96 03:25:09 pm 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 world, mikebo@tellabs.com had to walk into mine and say: > Previously, I wrote: > > I believe a bug has been introduced into the 2.1-960627-SNAP YP code. > > Previously, I had been able to use NIS netgroups in the password file: > > +@mygroup::::::::: > > > 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. 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. > > The FreeBSD client is bound to a SunOS 4.1.x server. When I attempt to > > login, FreeBSD attempts : > > NIS: ----- Network Information Service ----- > > NIS: Proc = 4 (Return first key-value pair in map) > > NIS: Domain = mydomain > > NIS: Map = master.passwd.byname > > > > Of course, my Sun NIS domain has no such map "master.passwd.byname", > > and that's the end of that. Yes, I know. The FreeBSD client is checking for the presence of the master.passwd.by{name,uid} maps. If it doesn't find them, it rolls over to the passwd.by{name,uid} maps. In other words, the behavior you are seeing is normal. > > The FreeBSD client goes on to try and get > > the passwd.byname entry for my login, which succeeds. Nevertheless, > > the login is refused. Here is a high-level packet trace: > > > > 1 0.00000 toybox -> sunc NIS C FIRST > > 2 0.01581 sunc -> toybox NIS R FIRST No such map > > 3 0.00321 toybox -> sunc NIS C MATCH mikebo in passwd.byname > > 4 0.01115 sunc -> toybox NIS R MATCH OK > > > > If I take the SunOS map entry from my account, and massage it to fit > > the format of the FreeBSD vipw, I am able to login just fine. This means > > that the password encryption and comparison is working. (Yes, DES is > > installed and working). > > > Let me rephrase my closing comments. I really need NIS password file > support to work. So do I. I hate it I tear my hair out working on code and just when I think I have it working exactly right, somebody finds a new set of conditions that I never thought to test for which breaks the whole mess. > Is anyone else seeing this problem? Is there anything > I should check out that might be incorrectly configured? Is anyone else > successfully using NIS password entries when bound to a SunOS server? Yes, I am. The getpwent.c module in the 2.1 SNAP and 2.1-stable tree is idendical to the one in -current, and I've been using -current without any problems using both a SunOS NIS server and the FreeBSD NIS server. What I would do is try to test the getpwent(3) routines by writing a small C program that calls getpwnam(). Here's an example: 1) Copy the src/lib/libc/gen/getpwent.c source file from the SNAP release you're using to a work directory. 2) Create a small C program (pwtest.c) like this: #include #include main() { struct passwd *pw; pw = getpwnam(argv[1]); printf("Username is: [%s]\n", pw->pw_name); printf("UID is: [%lu]\n", pw->pw_uid); printf("Password is: [%s]\n", pw->pw_passwd); exit(0); } 3) Compile the program like this: % cc -g -c pwtest.c % cc -g -c -DYP getpwent.c % cc -o pwtest pwtest.o getpwent.o 4) Run the program like this: $ pwtest nisuser where 'nisuser' is the username of a user that appears in the NIS passwd maps. (Try it with the +@myuser:::::::: entry too, just for kicks.) Check the output from this program and see if it makes sense. Print out all the fields if you want. Chances are that whatever the problem is will make itself evident when you see the output. If you see bogus output but you can't explain it, try stepping through the program with gdb. Since you have compiled the program with debugging, you'll be able to step through the getpwent(3) module and hopefully you'll be able to spot the problem. If you see bogus output but you still can't explain it even with the debugger, show us the output. Try to keep it as close to the original output as possible (some people don't want to e-mail their passwd database info to open mailing lists, but often when people make up replacement sample results they fail to preserve the glitch closely enough to allow proper debugging). If the output looks exactly correct, then expand the program to include a call to crypt(3) and compare the results with the encrypted password show in the pw_passwd field. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= License error: The license for this .sig file has expired. You must obtain a new license key before any more witty phrases will appear in this space. =============================================================================