From owner-freebsd-current Wed Aug 9 11:05:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA21921 for current-outgoing; Wed, 9 Aug 1995 11:05:04 -0700 Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA21895 ; Wed, 9 Aug 1995 11:04:59 -0700 Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.11/8.6.9) id OAA26176; Wed, 9 Aug 1995 14:03:49 -0400 From: A boy and his worm gear Message-Id: <199508091803.OAA26176@skynet.ctr.columbia.edu> Subject: proposed change to chpass(1) To: freebsd-current@freebsd.org Date: Wed, 9 Aug 1995 14:03:44 -0400 (EDT) Cc: bugs@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 3051 Sender: current-owner@freebsd.org Precedence: bulk Since this is a security-related sort of thing, I need to run it past people first before punching the big red 'commit' button. Comments are welcome and encouraged. Last night, a gentleman on IRC pointed out to me that chpass(1) is blazingly stupid with respect to NIS. If you invoke, say, chfn with NIS running, it will retrieve the password data for a user through the getpwent(3) library functions, which means it will grab the NIS information and treat is as local. When the user exits chpass, it gratuitously adds the modified record to /etc/master.passwd even though the user doesn't exist in the local master.passwd file. Another way to see this (which is not related to NIS) is to invoke chpass as the superuser. For example, the superuser can run 'chpass foouser' (where foouser is an existing valid user in the password database), change foouser's login name to 'baruser,' then exit. chpass will create a new password record for 'baruser' containing the same data as 'foouser' and append it to /etc/master.passwd. As near as I can tell from the code, this is intended behavior, though it's not documented in the man page. pw_copy() attempts to match the new record against an existing one and does a substitution when it finds a match, but if it _doesn't_ find a match, it just appends the new record to the end of /etc/master.passwd and rolls merrily along. I, for one, am not thrilled with this. Therefore, I propose the following change to /usr/src/usr.bin/chpass/pw_copy.c: *** pw_copy.c Wed Aug 9 13:46:59 1995 --- pw_copy.c.new Wed Aug 9 10:39:41 1995 *************** *** 96,105 **** --- 96,113 ---- goto err; } if (!done) + #ifdef TOO_LENIENT_FOR_OUR_OWN_GOOD (void)fprintf(to, "%s:%s:%d:%d:%s:%ld:%ld:%s:%s:%s\n", pw->pw_name, pw->pw_passwd, pw->pw_uid, pw->pw_gid, pw->pw_class, pw->pw_change, pw->pw_expire, pw->pw_gecos, pw->pw_dir, pw->pw_shell); + #else + { + warnx("%s: no such local user", pw->pw_name); + warnx("(use ypchpass(1) for NIS or adduser(1) to create a new user)"); + pw_error(NULL, 0, 1); + } + #endif if (ferror(to)) err: pw_error(NULL, 1, 1); This makes chpass abort without changing the password database rather than blindly adding a new record (passwd is already smart enough to know when NIS is turned on though and handles it accordingly). This is really a temporary fix since I intend to add NIS support to chpass eventually, but I won't have it ready for 2.1 and this needs to be addressed before then. -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~ "Welcome to All Things BSDish! If it's not BSDish, it's crap!" ~~~~~~~