From owner-freebsd-bugs Thu Jul 13 12:53:35 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA23420 for bugs-outgoing; Thu, 13 Jul 1995 12:53:35 -0700 Received: from sundance.itd.nrl.navy.mil (sundance.itd.nrl.navy.mil [132.250.92.89]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA23414 for ; Thu, 13 Jul 1995 12:53:32 -0700 Received: from localhost.itd.nrl.navy.mil by cs.nrl.navy.mil id aa19902; 13 Jul 95 20:52 GMT To: Mike Kephart cc: skey-users@thumper.bellcore.com, bugs@freebsd.org Subject: Re: OPIE and shadow passwords Date: Thu, 13 Jul 1995 15:52:18 -0500 From: Craig Metz Message-ID: <9507132052.aa19902@cs.nrl.navy.mil> Sender: bugs-owner@freebsd.org Precedence: bulk [In the future, please send OPIE bug reports to . That's what it's there for.] > As FreeBSD uses it's own form of shadow passwords, the encrypted >password fields in /etc/passwd have been replaced with "*" characters. >Thus, OPIE's lookupuser() in login.c and su.c fail, as they check to >see if the password is "stared out": We developed NRL OPIE 2.0 primarily on BSD/OS 2.0 and 4.4BSD. Both of these use the 4.4BSD shadow password system, which will properly fill in the pwent pw_passwd field if the calling process has the appropriate (usually superuser) priveleges. In my opinion, if the FreeBSD team decided to break this behavior, they have done the wrong thing. Are you sure that opielogin and opiesu are, in fact, receiving starred-out passwords, and that they are, in fact, running with appropriate priveleges? Assuming these are the case, then it looks like this is a FreeBSD "feature" that requires some kind FreeBSD user to send us the appropriate diffs. It would probably require implementation similar to that of the Solaris 2.x shadow password support, though I believe that FreeBSD's shadow password system uses MD5 instead of crypt (which might require an #ifdef around the call to crypt()). > return ((pwd->pw_passwd[0] == '*') || (pwd->pw_passwd[0] == '#')); > > My question is - would there be any real or theoretical weakness >introduced by removing this check. If not, what would be the "proper" >way to temporarily inactivate a user login? I believe that this check should not be messed with, both for historical reasons and for a completely practical one -- if the user lookup routines don't have a real encrypted password to compare against, you won't be able to do cleartext password checking (for use on the console). -Craig