Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!spool.mu.edu!sdd.hp.com!mips!cs.uoregon.edu!ns.uoregon.edu!milton!uw-beaver!zephyr.ens.tek.com!tekgen!sail!keithe
From: keithe@sail.LABS.TEK.COM (Keith Ericson)
Newsgroups: comp.unix.sysv386
Subject: Re: Needed: pcnfsd that knows about /etc/shadow
Keywords: a fix is enclosed....
Message-ID: <9072@sail.LABS.TEK.COM>
Date: 6 Mar 91 19:59:56 GMT
References: <9004@sail.LABS.TEK.COM> <1991Feb22.035906.11349@buster.stafford.tx.us> <15478@uudell.dell.com>
Reply-To: keithe@sail.LABS.TEK.COM (Keith Ericson)
Distribution: na
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 23

In article <15478@uudell.dell.com> sblair@upurbmw.dell.com (Steve Blair) writes:
}
}Here's a quick and simple way to avert any problems with pcnfsd.c A message
}pcnfsd...  uses getpwnam() to get the /etc/passwd entry for a particular user.
}...
}To correct this, I added code to pcnfsd.c (source to which is distributed with
}SUN's PC-NFS and FTP Software's PC/TCP) to additionally call getspnam() to 
}access the shadow password file to retrieve the user's password. This was 
}a trivial modification. 

This is certainly the way things *should* be done, and I've managed to
locate a getspname() in libsec.a, but the ISC 2.0.2 documentation in NO WAY
documents the use of the shadow file password system.  The AT&T Release
notes *mentions* the fact that the encrypted passwords have been moved to
the shadow file for security reasons, but that's all I've been able to find
on the subject...

	I have no idea how the library call(s) might be used to access the
shadow file.  

sigh....

kEITHe