/etc/shadow
MFHorn
arosen at hawk.ulowell.edu
Mon Nov 14 09:28:21 AEST 1988
>From article <8871 at smoke.BRL.MIL>, by gwyn at 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 at 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
More information about the Comp.unix.wizards
mailing list