Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ulowell!arosen@hawk.ulowell.edu From: arosen@hawk.ulowell.edu (MFHorn) Newsgroups: comp.unix.wizards Subject: Re: /etc/shadow Message-ID: <10187@swan.ulowell.edu> Date: 13 Nov 88 23:28:21 GMT References: <8871@smoke.BRL.MIL> Sender: news@swan.ulowell.edu Lines: 40 From article <8871@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > It also seems that the following are missing: > > "pwvalid" utility (necessarily privileged) to SLOWLY > check a (user,password) pair for validity. > > "int pwvalid(const char *user, const char *password)" > C library function that simply opens a pipe to the above > utility and returns true only when the arguments > constitute a valid pair. This is similar (maybe identical) to the approach I would take, where the idea is to turn off world read-access to /etc/passwd, but still allow users to get other information from /etc/passwd. 1: chmod 400 /etc/passwd 2: Write a server (passwdd) to accept connections from clients who request the password entry for a given user 3: Re-write getpw{ent,uid,nam} to connect to the client 4: Re-compile everything that uses getpw{ent,uid,nam} With this, you can very easily monitor all types of access to /etc/passwd, and restrict access to it, if desired. Passwdd should give the client all fields of the password entry except the encrypted password unless it is the entry of the requesting user or the user is superuser. Now, the only way to test what a user's password is, is to try to login with it. The result allows users to write their own programs that do validation by login password without breaking programs like finger, csh (~ expansion), ls (-l), whoami, and any others that look at /etc/passwd. Authenticating the client is the next problem... Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should've been