Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!zazen!news
From: keir@vms.macc.wisc.edu (Rick Keir, MACC)
Newsgroups: comp.sys.next
Subject: Re: How to restrict network logins on NeXT?
Message-ID: <1991Apr4.221805.10353@macc.wisc.edu>
Date: 4 Apr 91 22:12:26 GMT
Sender: news@macc.wisc.edu (USENET News System)
Organization: University of Wisconsin Academic Computing Center
Lines: 28

In article <1991Apr3.025924.12291@cs.ubc.ca>, majka@cs.ubc.ca (Marc Majka) writes...

>We solved a very similar problem at UBC with a modified shell for
>the "guest" account.  The source is included below.  Modify guest's
>shell to this one, and they will be able to login at the console, but
>not remotely.  Additionally, Stuart / Terminal / etc don't break.
> 
>You get what you pay for...
> 
Well, we just installed this, and it seems to work.  You can't
log in remotely, nor log in with a better account and then
"su" to guest, nor log in at the console as guest and *then*
telnet back to the same account (not that I care about people
doing that, but it doesn't work, all the same...).  So this
seems to work pretty well.  Thanks!

By the way, if anyone installs this, don't forget to modify
/etc/shells to include this one;  otherwise, the guest account
won't be able to be used from the console, either.  This is not
very obvious to those who, like me, have had most of their Unix
experience as users and not as administrators;  this is the first
time I've been both able & required to worry about such things.
Fortunately, I'd already been examining /etc to see what
files I should worry about, so I figured out what happened
quite quickly.  

--- rick (who is now returning to use of a more secure 
    machine...)