keir@vms.macc.wisc.edu (Rick Keir, MACC) (04/02/91)
We have a NeXT we use for demonstration purposes here, which is
set up on our local ethernet. It also has a guest account,
intended for use by people who come into our consulting
area and actually sit at the NeXT's "console".
Is it possible to restrict access such that
(1) a single account (guest) must log in only from
the console
(2) guest can nevertheless use telnet/rlogin/ftp
facilities to communicate *from* our machine
to machines elsewhere (a common desire in testing)
(3) guest can still startup shell sessions (via
Terminal or Stuart or whatever...) when at the console
(4) OTHER account holders --- i.e., all "real person"
accounts --- can still rlogin from other machines to
the NeXT.
We want *local* guest users to be able to look at a real,
networked machine, without competing with remote guest
users in the background bogging down the machine with
troff, etc.
Solutions that involve preventing unassisted logins by total
strangers who walk up to the machine & read the directions are
unacceptable for social reasons; it is a very strongly held
principle that our machines should be easy to use without
needing "permission"; we *want* people to come in & mess
around.
Similarly, solutions that would drastically alter the environment
the local guest user has are unacceptable; they are supposed to
be able to see a close approximation of what their own NeXT would
be like. We're just trying to cut down on misleading CPU loads
caused by invisible users logging in from other machines, unknown
to the person testing the NeXT.majka@cs.ubc.ca (Marc Majka) (04/03/91)
Rick Keir, MACC writes: >Is it possible to restrict access such that ... 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... --- Marc Majka System Manager (for 3 more days) UBC Computer Science - - - Custom Shell - - - #include <stdio.h> #define SHELL "/bin/csh" main(argc,argv) int argc; char *argv[]; { int console; /* If not a login shell, just exec and be quiet */ if (!strcmp(argv[0],"-")) { execvp(SHELL,argv); exit(0); } console = !strcmp(ttyname(0), "/dev/console"); if (!console) { fprintf(stderr,"Remote login disabled (%s)\n",ttyname(0)); exit(0); } execlp(SHELL,"-cscsh",0); exit(0); }
keir@vms.macc.wisc.edu (Rick Keir, MACC) (04/05/91)
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...)