unix system enhancements

[Chris Torek]

In article <4119 at brl-smoke.ARPA> Geoffm at AFSC-HQ.arpa (USAFA) writes:
[wants to]
>1.  Modify CSH so that it checks for the existence of a system wide
>.cshrc and .login (obviously they could have different names) before
>reading the users .cshrc and .login.

It would be far easier to create accounts with .cshrc and .login files
that read

	source /usr/local/lib/cshrc

and

	source /usr/local/lib/login

This requires no source changes, which is a distinct advantage
these days, what with upgrading from 4.2 to 4.3alpha to 4.3beta
to 4.3beta++ to 4.3 to . . . ?

>2.  Modify /etc/login so that it checks a file to determine if
>the user is allowed to login over that line or network connection
>or dial-up port at that time of the day.

This could be done without source changes by giving users special
`shells' that do that check before switching to /bin/csh.  We felt
that login was important enough to hack, though; and Fred Blonder
came up with a nice general mechanism which I will now advocate
publicly:

Whenever a user logs in, we look for a file with that user's name
in the directory /etc/restrict/login.  If the file exists, it is
run.  If it returns a successful exit code (0), the user may log
in, otherwise not.  These files are typically shell scripts, e.g.:

	# dcuug (D.C. Unix User's Group) login script
	if
		echo \^`tty`$ | grep -s -f /etc/restrict/dialups
		then
		if
			who | fgrep dcuug # | fgrep -s -f /etc/restrict/dialups
		then
			echo Sorry, but someone\'s already logged in to dcuug on
			echo one of our dial-in lines. Since we have few, we
			echo only allow one dcuug login from dialup at a time.
			echo
			exit 1
		fi
	fi
	if
		/usr/local/bin/load -s 10
	then
		echo Sorry, but the system load is too high to allow guests on.
		echo Please try back later.
		echo
		exit 1
	fi
	exit 0

>3.  And lastly modify the tty driver to support "advising."

This is best done without modifying the kernel.  In particular, it
makes more sense to write a program that opens a pty and a socket,
and listens to both.  The pty acts as the user's terminal; the
socket listens to the `administrator'.  A separate program is run
by the administrator; this can have whatever controls are desired
to switch from `advising' mode to `commanding' mode or whatnot.

(In fact, we have such a program, though I believe it is currently
broken.  We have a rather peculiar window system and window-based
shell that supports `window cloning'.  A cloned window copies
whatever is done on the remote window.  The other window need not
be on the same machine, as the system uses Internet sockets.  I
would tell you who wrote it, but I think he is rather embarrassed
at the internals, as he wrote this while simultaneously learning
C, Unix, and networking.  No doubt he would not want to distribute
it in its current form.  Nevertheless, it was indeed once working,
and I think it provides a nice model.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu