Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!seismo!dimacs.rutgers.edu!rutgers!ucsd!nosc!humu!pilikia!art
From: art@pilikia.pegasus.com (Arthur Neilson)
Newsgroups: comp.sys.ncr
Subject: Re: shadow passwd in Tower 500 OS 1.01.02
Message-ID: <1991Jun25.181708.3607@pilikia.pegasus.com>
Date: 25 Jun 91 18:17:08 GMT
References: <1991Jun21.202108.18914@bohtsg.UUCP>
Organization: Pilikia, Honolulu
Lines: 25

In article <1991Jun21.202108.18914@bohtsg.UUCP> art@bohtsg.pegasus.com (Art Neilson) writes:
>I recently tried to implement shadow passwords in our Tower 500
>OS 1.01.02.  Everything seems to work fine except for va.  /bin/login,
>/bin/su and other system utilities behave correctly in the presence
>of /etc/shadow.  /bin/passwd correctly updates /etc/shadow with new
>passwords, and /bin/login looks up passwords in /etc/shadow instead of
>/etc/passwd as does /bin/su.  Unfortunately /va/obj/va which is invoked
>by /va/obj/vastart (va's login shell) detects the presence of /etc/shadow
>and complains that you must remove the shadow password option before
>va will work.  Why is va crippled in this regard ?  We are a Banking

Heh.  It turns out that /va/obj/ofinterpret is the guilty party, he
checks for the existence of the file /etc/shadow, displays an error
message and exits if it is found.  It's easy to use a hex editor and
search for the ascii string "/etc/shadow" in the ofinterpret binary,
once located set all 11 bytes to binary zeroes.  This will allow
va to run in the presence of /etc/shadow.  The system utilities such
as /bin/login, /bin/su and /bin/passwd already know what to do with
the shadow file, you just have to create it.  It should be easy to
create an awk script to automate the migration task.  I now have the
undocumented shadow password option running fine on our Tower 500
OS 1.xx in spite of va.
-- 
Arthur W. Neilson III		| INET: art@pilikia.pegasus.com
Bank of Hawaii Tech Support	| UUCP: uunet!ucsd!nosc!pilikia!art