pjh@mccc.uucp (Pete Holsberg) (09/12/90)
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. However, I would like to be able to terminate the login process if that user fails to select a password. I though I would examine the return code of the passwd command and then exit if it's not 0. BUT, simply executing "exit" doesn't abort the login; it aborts /etc/profile! What can I execute to terminate the login of a user who fails to select a valid password? Thanks, Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
rickert@mp.cs.niu.edu (Neil Rickert) (09/12/90)
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 The way I handle new accounts is as follows: The initial shell is the restricted shell. (Actually the restricted kshell, or to be more precise a local front end which just execs to the restricted kshell. /etc/profile detects the restricted shell (the $SHELL variable), and sets a path with a very minimal set of commands. In this case 'passwd' is a shell script which invokes the real passwd command, and then check for a changed password. If the password is changed, and if there is not non-empty file named SUSPEND in the users home directory, then the shell script invokes 'chsh' to provide a decent shell, copies standard startup files to the home directory if they are not present, and recommends that the user logout then login again. A practical application is to set up new student accounts with no password, the restricted shell, a non-empty SUSPEND owned by the course instructor, and the home directory not publically readable. When the student establishes a password the directory is made readable. That allows the instructor to validate the account by copying /dev/null to SUSPEND. At the next login the .profile detects this, changes the shell etc. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
jms@tardis.Tymnet.COM (Joe Smith) (09/12/90)
In article <1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes:
on one of my systems (3B2.400 SVR3.1)
executing "exit" doesn't abort the login; it aborts /etc/profile!
I have seen that "stty 0" works on BSD systems, does it work on AT&T?
--
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P,"
San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."mark@hsi.UUCP (Mark Sicignano) (09/12/90)
In article <1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >However, I would like to be able to terminate the login process if that >user fails to select a password. I though I would examine the return >code of the passwd command and then exit if it's not 0. BUT, simply >executing "exit" doesn't abort the login; it aborts /etc/profile! What >can I execute to terminate the login of a user who fails to select a >valid password? > Assuming that you have a script called chkpasswd that you call from your .login or .profile (or /etc/profile, whatever) and chkpasswd exits with 0 on success or something else on failure, that can't you test the return value from chkpasswd and based on that do a kill -1 $$ ? $$ is the pid of the current shell. -mark -- Mark Sicignano ...!uunet!hsi!mark 3M Health Information Systems mark@hsi.com --
cpcahil@virtech.uucp (Conor P. Cahill) (09/12/90)
In article <1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >code of the passwd command and then exit if it's not 0. BUT, simply >executing "exit" doesn't abort the login; it aborts /etc/profile! What >can I execute to terminate the login of a user who fails to select a >valid password? Send a signal to process id zero (i.e. kill 0) which will send the signal to all processes in that process group. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
mathisen@dali.cs.montana.edu (Jaye Mathisen) (09/12/90)
In article <1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >code of the passwd command and then exit if it's not 0. BUT, simply >executing "exit" doesn't abort the login; it aborts /etc/profile! What >can I execute to terminate the login of a user who fails to select a >valid password? Well, long ago I ran into something like this. My cheap cop-out kludge was to 'exec /bin/login', and let things run their course. If they didn't log in in the timeout interval, getty would takeover, otherwise if they got logged in, the user would have another chance to get things right.
jgreely@morganucodon.cis.ohio-state.edu (J Greely) (09/12/90)
In article <1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >code of the passwd command and then exit if it's not 0. BUT, simply >executing "exit" doesn't abort the login; it aborts /etc/profile! What >can I execute to terminate the login of a user who fails to select a >valid password? I use "exec /bin/false". -- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
dmh@sq.sq.com (David Harrison) (09/12/90)
In article <1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: >However, I would like to be able to terminate the login process .. >BUT, simply executing "exit" [in /etc/profile] doesn't abort the >login; it aborts /etc/profile! What can I execute to terminate >the login of a user ... "kill -9 0" has worked for me in Sys III, SysV.3, and now SunOS. Also: >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. Beware: the passwd(1) command tries to keep two users from simultaneously editing the password file by creating a tmp file in /etc: if that file already exists passwd refuses to run for a second user. This can lead to a race condition if two users invoke passwd at almost the same time, and under suitable conditions you can end up with no password file at all! I used to have my 1400 undergraduates choose their own passwords, and ended up surrounding passwd with a wrapper that put up a semaphore to avoid the race; I don't know how we would do it under SunOS. (We abandoned the scheme because too many students forgot what they had chosen; now a much smaller percentage of them lose the paper we give them with the password on it. :-{ ) -- David Harrison, Dept. of Physics, Univ. of Toronto, harrison@faraday.physics.utoronto,ca ..uunet!utgpu!utfyzx!harrison (Just reading the news at SoftQuad; not affiliated with them and they ain't responsible for me at all.)
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (09/12/90)
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
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/12/90)
In article <1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes: | I though I would examine the return | code of the passwd command and then exit if it's not 0. BUT, simply | executing "exit" doesn't abort the login; it aborts /etc/profile! What | can I execute to terminate the login of a user who fails to select a | valid password? "kill -1 $$" should do it. I believe that you can simplify this by assigning no password but using the password ageing feature of SysV to force selection of a new password at login. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
skwu@boulder.Colorado.EDU (WU SHI-KUEI) (09/13/90)
Giving the user a dummy password with password aging turned on and the aging data set properly will do the trick. I don't have my manuals handy, so I can't tell you exactly how to set the aging data.
rdc30med@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) (09/13/90)
In article <544@fciva.FRANKLIN.COM> dag@fciva.UUCP (Daniel A. Graifer) writes: > >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. It indeed does. A ',' after the encryption field defines the beginning of the passwd aging and last changed fields. It is stored as four alphanumeric values, the first two being the min and max password age values and the last two defining the last changed date. On my system, all new users have ',B3' in the passwd field of /etc/passwd. This forces all new users to assign a password at first login and they can't by-pass it. It also forces them to choose a new password every 120 days and prevents them from changing for 30 days after the last change. See the passwd man page on Sys V for details and what the field values mean. -- Mike Dobson, Sys Admin for | Internet: rdc30med@nmrdc1.nmrdc.nnmc.navy.mil nmrdc1.nmrdc.nnmc.navy.mil | UUCP: ...uunet!mimsy!nmrdc1!rdc30med AT&T 3B2/600G Sys V R 3.2.2 | BITNET: dobson@usuhsb.bitnet WIN/TCP for 3B2 | MCI-Mail: 377-2719 or 0003772719@mcimail.com
cep@cci632.UUCP ( co-op) (09/13/90)
In article <1220@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >I have seen that "stty 0" works on BSD systems, does it work on AT&T? Hehe...under v7 (back when I was a little irresponsible terror) I used to stty 0 > /dev/ttyxx to hang up on people I didn't like. (Don't worry, I have matured; now it's my turn to frown upon such activities). The problem is what it does if you're rlogin'ed or telnetted in -- at least under one of the RIT machines I use, the baud rate has no effect and so stty 0 wouldn't do anything. You're better off with kill -1 $$ or kill -1 0. Chris/WZ2B
paul@unhtel.uucp (Paul S. Sawyer) (09/15/90)
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. > >However, I would like to be able to terminate the login process if that >user fails to select a password. I though I would examine the return >code of the passwd command and then exit if it's not 0. BUT, simply >executing "exit" doesn't abort the login; it aborts /etc/profile! What >can I execute to terminate the login of a user who fails to select a >valid password? If you set the password field to ',..' (comma-dot-dot) login should make the user set the password before continuing. This sounds like what you want, unless I'm missing something. Good luck. -- Paul S. Sawyer uunet!unh!unhtel!paul paul@unhtel.UUCP UNH Telecommunications attmail!psawyer p_sawyer@UNHH.BITNET Durham, NH 03824-3523 VOX: +1 603 862 3262 FAX: +1 603 862 2030
pjh@mccc.uucp (Pete Holsberg) (09/15/90)
In article <1990Sep11.201345.18277@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: =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 = = The way I handle new accounts is as follows: = = The initial shell is the restricted shell. (Actually the restricted =kshell, or to be more precise a local front end which just execs to the =restricted kshell. My Korn Shell (from Aspen) doesn't mention a restricted ksh. = /etc/profile detects the restricted shell (the $SHELL variable), and =sets a path with a very minimal set of commands. In this case 'passwd' =is a shell script which invokes the real passwd command, and then check =for a changed password. = = If the password is changed, and if there is not non-empty file named =SUSPEND in the users home directory, then the shell script invokes ='chsh' to provide a decent shell, copies standard startup files to the =home directory if they are not present, and recommends that the user =logout then login again. Not a bad idea. However, I got many suggestions on logging people off and one or two about just setting up a loop whereby the user was forced to enter a password, no matter what. I did the former on the dial-up machine and the latter on the "terminal" one. My thanks to all who responded. Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
pjh@mccc.uucp (Pete Holsberg) (09/15/90)
In article <544@fciva.FRANKLIN.COM> dag@fciva.UUCP (Daniel A. Graifer) writes: =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). Unfortunately, AT&T SVR3.1.2 doesn't have shadow passwords, and login thinks that ",.." in the password field of /etc/passwd is a password! =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 am, but your SV is better than my SV! I do not have passwd(1M). Thanks, anyway! Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91
les@chinet.chi.il.us (Leslie Mikesell) (09/18/90)
In article <1990Sep15.002036.17056@mccc.uucp> pjh@mccc.edu (Pete Holsberg) writes: > > I am, but your SV is better than my SV! I do not have passwd(1M). I wouldn't say better.... I really hate it when someone touches the uucp logins on the 386's with the FACE admin package or changes the password with passwd(1). These things idiotically activate password aging so in about a month the uucp dial-ups to them will start failing, sitting at a prompt that says "Your password has expired, please choose a new one". After several days of wasted LD calls, someone usually notices that things are broken.... Yes, you can turn it off, if you remember every time. Besides, your SV does have password aging, it just doesn't cram it down your throat. See passwd(4) for a description of how to set it up with your favorite editor. Les Mikesell les@chinet.chi.il.us
rbp@investor.pgh.pa.us (Bob Peirce #305) (09/18/90)
In article <1220@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: > >I have seen that "stty 0" works on BSD systems, does it work on AT&T? Yes. However, it has left jobs running so that when you dial back in you are still logged on, so we try to kill all the jobs first. -- Bob Peirce, Pittsburgh, PA 412-471-5320 ...!uunet!pitt!investor!rbp rbp@investor.pgh.pa.us
woods@eci386.uucp (Greg A. Woods) (09/19/90)
In article <1990Sep15.002036.17056@mccc.uucp> pjh@mccc.edu (Pete Holsberg) writes: > In article <544@fciva.FRANKLIN.COM> dag@fciva.UUCP (Daniel A. Graifer) writes: > =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). > > Unfortunately, AT&T SVR3.1.2 doesn't have shadow passwords, > and login thinks that ",.." in the password field of /etc/passwd > is a password! Don't get confused here by the abundance of information! :-) The "aging" feature was added sometime around SysVr3.0 or even 2.2. Shadow passwords are 3.2 or so, and a little bit different kettle of fish. ",.." in the second (password) field of /etc/passwd certainly worked on my AT&T 3B2/400 running SysVr3.1v2 (at least before the lightning fried it a couple of weeks ago....). > =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 am, but your SV is better than my SV! I do not have passwd(1M). It should be in the Administrator's Reference Manual, which if you don't have a copy of, you should. However, I can't check my 3.1 manuals today, since they are at home. Meanwhile, I note the 3.0/386 manuals do not mention anything specific, nor does SVID-vol.1 or 2. However, I've just checked our little AT&T 3b1, (SysVr2.2 derivative), and it supports full password aging. Certainly this 386 does as well, regardless of what the manual says. AT&T has a habit of adding features, but not documenting them for several releases, if ever. Perhaps password aging is a compile time option in older login's and passwd's, thus it is up to the vendor to turn it on. Another infamous example of this is /etc/issue. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
bote@csense.uucp (John Boteler) (09/20/90)
From article <1990Sep15.002036.17056@mccc.uucp>, by pjh@mccc.uucp (Pete Holsberg): > Unfortunately, AT&T SVR3.1.2 doesn't have shadow passwords, > and login thinks that ",.." in the password field of /etc/passwd > is a password! Oh. Maybe it's time for everybody to bug John F. Haugh again to revitalize his PD login suite. Really nice, with shadow passwords, maintenance utilities, etc. -- John Boteler bote@csense.uucp {uunet | ka3ovk}!media!csense!bote SkinnyDipper's Hotline: 703-241-BARE | VOICE only, Touch-Tone(TM) signalling
ag@cbmvax.commodore.com (Keith Gabryelski) (10/11/90)
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. > >However, I would like to be able to terminate the login process if that >user fails to select a password. I though I would examine the return >code of the passwd command and then exit if it's not 0. BUT, simply >executing "exit" doesn't abort the login; it aborts /etc/profile! What >can I execute to terminate the login of a user who fails to select a >valid password? Remember that a user may hit the interupt key before your script starts, thus aborting /etc/profile and your password scheme. Even placing a `trap' at the start of /etc/profile will not help this (since on a user could hit the interupt character before the trap was executed). Pax, Keith ``Just catching up on 3 weeks of unread news'' Gabryelski
craig@attcan.UUCP (Craig Campbell) (10/12/90)
In article <15051@cbmvax.commodore.com> ag@cbmvax.commodore.com (Keith Gabryelski) writes: >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. >> >>However, I would like to be able to terminate the login process if that >>user fails to select a password. I though I would examine the return >>code of the passwd command and then exit if it's not 0. BUT, simply >>executing "exit" doesn't abort the login; it aborts /etc/profile! What >>can I execute to terminate the login of a user who fails to select a >>valid password? > >Remember that a user may hit the interupt key before your script >starts, thus aborting /etc/profile and your password scheme. Even >placing a `trap' at the start of /etc/profile will not help this >(since on a user could hit the interupt character before the trap was >executed). > > >Pax, Keith ``Just catching up on 3 weeks of unread news'' Gabryelski How about enabling password aging? Here is a qoute from an old manual (we are at UNIX 3.2.2 which is slightly different.) Quote from AT&T 3B2 Computer, Unix (r) System V Release 3, User's and System Administrator's Reference Manual PASSWD(4) ..." Password aging is -effected for a particular user if his encrypted password in the password file is followed by a comma and a non-null string of characters fromt the above alphabet. (oops...alphabet is (., /, 0-9, A-Z, a-z) - craig (-: ) (Such a string must be introduced in the first instance by the super-user.) The first character of age, M say, denotes the maximum number of weeks for which a password is valid. A user who attempts to login after his password has expired will be forced to supply a new one. The next character, m say, denotes the minimum period in weeks that must expire before the password may be changed. The remaining one or two characters define the week (counted from the beginning of 1970) when the password was last changed. (A null string is equivalent to zero.) M and m have numberical values in the range 0-63 that correspond to the 64-character alphabet shown above (i.e. / = 1 week; z = 63 weeks). If m = M = 0 (derived from the the string . or ..) the user will be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ forced to change his password the next time he logs in (and the "age" will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ disappear from his entry in the password file). If m > M (signified, e.g., by the string ./) only the super-user will be able to change the password." Hope this solves your problem, craig
mst@mx.csun.edu (Michael Temkin) (10/14/90)
In article <15051@cbmvax.commodore.com> ag@cbmvax.commodore.com (Keith Gabryelski) writes: >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. >> >>However, I would like to be able to terminate the login process if that >>user fails to select a password. I though I would examine the return >>code of the passwd command and then exit if it's not 0. BUT, simply >>executing "exit" doesn't abort the login; it aborts /etc/profile! What >>can I execute to terminate the login of a user who fails to select a >>valid password? > >Remember that a user may hit the interupt key before your script >starts, thus aborting /etc/profile and your password scheme. Even >placing a `trap' at the start of /etc/profile will not help this >(since on a user could hit the interupt character before the trap was >executed). > > >Pax, Keith ``Just catching up on 3 weeks of unread news'' Gabryelski Actually, I was thinking that if this is ONLY on first login of a new account, create a script/program that is inserted as the users shell. The "code" would execute /bin/passwd, then /usr/bin/chsh to change the shell to something more appropriate. Afterwards, it would exec to the new shell. Besides enforcing the "SET A PASSWORD" situation, it lets users either select their own choice of shell, or it will let you (if chsh is restricted) set it when someone uses their account. In this way, accounts that have been handed out, but not accessed are easy to find and investigate why an account was given out and is not being used... Just some thoughts... Mike. -- Mike Temkin mst@csun.edu Cal. State U. Northridge, School of Engineering and Computer Science Voice phone: (818) 885-3919
FISH@LIVERPOOL.AC.UK (10/19/90)
I know this might sound a little obvious but have you tried sourcing the script that checks if the entry in /etc/passwd is has no password set rather than running it? Remember scripts are run in a sub shell so exit will exit from this sub shell rather than the login shell? I thought that you could perhaps try running login again but this will not if you are not in the login shell. Alternatively you could exit from your script with the return code from passwd and use it in the top-level script. Hope this is of some use. Francis Fish Programmer / Analyst Liverpool University Computer Laboratory fish@uk.ac.liverpool