Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.i386
Subject: Re: Using "getpwent" in SYSV/386
Message-ID: <11666@smoke.BRL.MIL>
Date: 22 Nov 89 21:53:47 GMT
References: <785@ctdi.UUCP> <11633@smoke.BRL.MIL> <2941@levels.sait.edu.au>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <2941@levels.sait.edu.au> CCDN@levels.sait.edu.au (david newall) writes:
>I would have thought it reasonable for getpwent to fill in the pw_passwd
>field if it was invoked by root.  Alternatively, I would have thought
>"getshadowent" routines would have been provided (for the exclusive use
>of root processes).

This is thinking the wrong way about encrypted passwords.  The encryption
is intended to be a ONE-way operation; therefore reading back the result
is not in line with the design of the password scheme.  Also, implementation
of encryption should be isolated from applications (so that it can be changed
if necessary without breaking existing applications).  Requiring infinite
privileges in order to test password validity is also not a wise policy.

What you really need is a function that validates an UNencrypted putative
password against the encrypted version; that is the only valid use of the
encrypted password.  Such a validating function would of course have to
at some point exploit temporary privileges in order to access the shadow
file.  It should also be fairly slow, to make it useless in batch password
cracking.  I don't know whether your system provides such a function or not.