Date: Mon, 8 Jul 1996 19:10:45 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: mikebo@tellabs.com Cc: bugs@freebsd.org Subject: Re: 2.1-960627-SNAP: YP problem Message-ID: <199607082310.TAA17851@skynet.ctr.columbia.edu> In-Reply-To: <199607081536.KAA20487@sunc210.tellabs.com> from "mikebo@tellabs.com" at Jul 8, 96 10:36:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
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 <some NIS user>' 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 <stdio.h>
> #include <pwd.h>
> #include <des.h> <---- 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."
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607082310.TAA17851>