Xref: utzoo comp.unix.admin:102 comp.unix.shell:136
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!fciva!dag
From: dag@fciva.FRANKLIN.COM (Daniel A. Graifer)
Newsgroups: comp.unix.admin,comp.unix.shell
Subject: Re: Logging a User Off
Message-ID: <544@fciva.FRANKLIN.COM>
Date: 12 Sep 90 12:31:08 GMT
References: <1990Sep11.173008.274@mccc.uucp>
Reply-To: dag@fciva.UUCP (Daniel A. Graifer)
Organization: Franklin Capital Investments, Inc. McLean, Va.
Lines: 31

In article<1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes:
>For reasons that are beyond the scope of this question, all new logins
>on one of my systems (3B2.400 SVR3.1) get no initial password.  I've
>written a little script that I put into /etc/profile.  It examines the
>password field of /etc/passwd for the user logging in and runs the
>passwd program if the password field is empty.  
>...
>Pete

Most of the responses I've seen have concentrated on bombing out a login.  In
fact, at some point, AT&T added a mechanism to do exactly what you want.  My
version of AT&T unix (Prime Sys V 3.1 r2) permits 'aging' of passwds (which
are actually stored in the /etc/shadow file).

I see you are on a SV machine, so you should check the passwd(1M) entry for
the -s (status), -l (lock), -x (expire days), -n(minimum days), and -f (force
change at next login) options.  

I believe the passwd mechanism supported this before the options for managing
it were added to /bin/passwd.  You should find the file format for /etc/passwd
(I believe it is in section 4 of the Programmer's Reference Manual).  There is
some combination of characters which are not valid encryption results (ex. ",",
".", and "/") that are appended to the encrypted password field.  I forget 
where the 'last change date' is stored.

Good luck,
Dan
-- 
Daniel A. Graifer			Franklin Mortgage Capital Corporation
uunet!dag@fmccva.franklin.com		7900 Westpark Drive, Suite A130
(703)448-3300				McLean, VA  22102