Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!comp.vuw.ac.nz!waikato.ac.nz!bcs From: bcs@waikato.ac.nz Newsgroups: comp.unix.questions Subject: Message-ID: <1991Jun18.152503.4001@waikato.ac.nz> Date: 18 Jun 91 03:25:02 GMT References: <27106@adm.brl.mil> <44240@netnews.upenn.edu> <44248@netnews.upenn.edu> Organization: University of Waikato, Hamilton, New Zealand Lines: 32 In article <44248@netnews.upenn.edu>, chip@pender.ee.upenn.edu (Charles H. Buchholtz) writes: > When I want to lock an account I change the shell to something that > will print out an explanation. This is nicer for the person being > locked out. It also prevents login, rlogin, telnet, , rsh, and ftp > (because the shell is not listed in /etc/shells). > I adopted a slightly different approach when I had a less-than-trustworthy student thrust apon one of our HP-UX systems. We decided it should have access only when the lab was supervised, so I added some logic into /etc/csh.login to check for the existance of a file named after the user currently logging in. If found, issue a cute message and logout, other- wise continue as normal. A csh script run by cron removes the file to allow the peasent to login, and recreates it (and kills said peasent) at the end of it's allowed session - all without intervention. I found pros and cons here: csh.login had to ignore interrupts, and I had to place an ACL restiction on "chsh" (couldn't be bothered doctoring /etc/profile); on the other hand, it does allow me to implement time restrictions on individual users with zilch trouble. The student is in no doubt as to why it can't log in, and logs out promptly as the end-point nears. Brent. -- +-Brent Summers, U of Waikato, NZ----------------------------------------+ | "Laugh and the world ignores you. Crying doesn't help either." | | All opinions expressed are, of course, solely my own errors. | +------------------------------------------------------bcs@waikato.ac.nz-+