keithe@sail.LABS.TEK.COM (Keith Ericson) (02/21/91)
I'd appreciate it if I could get a pointer to the solution to a problem that _must_ have been solved already: systems employing the /etc/shadow file for password storage fail to authenticate prospective pcnfsd users. The pcnfsd as delivered - or as compiled from Sun's PC-NFS source - is unaware that the encrypted password doesn't live in /etc/passwd anymore. (Or is it just that the getpwent(3c) functions aren't aware of it?) Anyway - please send pointers, directions, code/code-fragments, whatever to me at keithe@sail.labs.tek.com By the way, this is for ISC 2.0.2 and their ethernet/nfs package. (I also have an ESIX Rev. D system; it seems to work just fine...) Thank you very much. kEITHe
sblair@upurbmw.dell.com (Steve Blair) (02/25/91)
[a customer emailed this fix to us, thought it'd share it] Here's a quick and simple way to avert any problems with pcnfsd.c A message from someone posted to comp.unix.sysv386 clued me in on what was going on. pcnfsd, as distributed by SUN, doesn't support shadow password files. It uses getpwnam() to get the /etc/passwd entry for a particular user. Under your UNIX, the passwd structure returned does not include the encrypted password. Because of this, it didn't have a password to compare against the one I was passing over from the PC NFS client and so it failed the mount every time. 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. -- Steve Blair DELL UNIX DIVISION sblair@upurbmw.dell.com ================================================================
jdeitch@jadpc.cts.com (Jim Deitch) (02/26/91)
In article <15478@uudell.dell.com> sblair@upurbmw.dell.com (Steve Blair) writes: >[a customer emailed this fix to us, thought it'd share it] > >Here's a quick and simple way to avert any problems with pcnfsd.c A message >from someone posted to comp.unix.sysv386 clued me in on what was going on. >pcnfsd, as distributed by SUN, doesn't support shadow password files. It >uses getpwnam() to get the /etc/passwd entry for a particular user. Under your >UNIX, the passwd structure returned does not include the encrypted password. >Because of this, it didn't have a password to compare against the one I was >passing over from the PC NFS client and so it failed the mount every time. >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. > > > > >-- >Steve Blair DELL UNIX DIVISION sblair@upurbmw.dell.com >================================================================ You will find this true of most of the bsd stuff. I ported pop and uucpd from BSD and had to do the mods. Be advised that the structures between passwd and shadow are a little different, along with the routines that you have to use. Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
keithe@sail.LABS.TEK.COM (Keith Ericson) (03/07/91)
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
cpcahil@virtech.uucp (Conor P. Cahill) (03/11/91)
keithe@sail.LABS.TEK.COM (Keith Ericson) writes: >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 Yes it does. Read the Integrated Software Development Guide, Appendix A and you will find a manual page for getspent(3X) and its associated functions. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170